ETSITS132 225V5.1.0 



(2002-12) 



Technical Specification 

Digital cellular telecommunications system (Phase 2+); 
Universal Mobile Telecommunications System (UMTS); 

Telecommunication management; 

Charging management; 

Charging data description 

for the IP Multimedia Subsystem (IMS) 

(3GPP TS 32.225 version 5.1.0 Release 5) 



33i^ 



GS 




® 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 





3GPP TS 32.225 version 5.1 .0 Release 5 1 ETSI TS 1 32 225 V5.1 .0 (2002-1 2) 



Reference 



RTS/TSGS-0532225V51 
Keywords 



GSM, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, send your comment to: 
editor(a)etsi.orq 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2002. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade Marks of ETSI registered for the benefit of its Members. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 32.225 version 5.1 .0 Release 5 2 ETSI TS 1 32 225 V5.1 .0 (2002-1 2) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

All published ETSI deliverables shall include information which directs the reader to the above source of information. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http ://webapp . etsi .org/ke y/queryform. asp . 



ETSI 



3GPP TS 32.225 version 5.1 .0 Release 5 3 ETSI TS 1 32 225 V5.1 .0 (2002-1 2) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 6 

1 Scope 7 

2 References 7 

3 Definitions, symbols and abbreviations 8 

3.1 Definitions 8 

3.2 Symbols 8 

3.3 Abbreviations 8 

4 Offline and Online Charging 9 

4.1 Implementation of Offline and Online Charging 9 

4.1.1 Usage of Rf and Ro Interfaces 9 

4.1.2 Usage of Rf and ISC Interfaces 9 

4.1.3 Support of Local File Storage 10 

4.2 Diameter Protocol Basic Principles and Use 10 

4.2.1 Basic Principles 10 

4.2.2 Application Requirement for the Base Protocol 10 

4.2.2.1 Offline Specific Base Protocol Requirements 10 

4.2.2.2 Online Specific Base Protocol Requirements 10 

4.2.2.3 Security Considerations 11 

5 Offline Charging 11 

5.1 Diameter Description on the Rf Interfaces 11 

5.1.1 Basic Principles 11 

5.1.2 Message Flows and Types 12 

5.1.2.1 Message Flows - Successful Cases and Scenarios 12 

5.1.2.1.1 Session Related Procedures 12 

5.1.2.1.2 Session-Unrelated Procedures 18 

5.1.2.1.3 PSTN Related Procedures 19 

5.1.2.1.4 MRFC Related Procedures 22 

5.1.2.1.5 AS Related Procedures 24 

5.1.2.2 Message Flows - Error Cases and Scenarios 27 

5.1.2.2.1 Error Cases - Session Related SIP Procedures 27 

5.1.2.2.2 Error Cases - Session Unrelated SIP procedures 27 

5.1.2.2.3 Error Cases - Diameter procedures 27 

5.1.3 Message Formats 28 

5.1.3.1 Summary of Offline Charging Message Formats 28 

5.1.3.2 Structure for the Accounting- and Abort-Session Message Formats 28 

5.1.3.2.1 Accounting-Request Message 29 

5.1.3.2.2 Accounting-Answer Message 31 

5.1.3.2.3 Abort-Session-Request 31 

5.1.3.2.4 Abort-Session- Answer 32 

5.1.3.3 Detailed Message Formats 32 

5.2 CDR Description on the Bi Interface 34 

5.2.1 CDR Field Types 34 

5.2.2 CDR Triggers 35 

5.2.2.1 Session Related CDRs 35 

5.2.2.2 Session Unrelated CDRs 35 

5.2.3 CDR Content 35 

5.2.3.1 Charging Data in S-CSCF (S-CSCF-CDR) 35 

5.2.3.2 Charging Data in P-CSCF (P-CSCF-CDR) 37 

5.2.3.3 Charging Data in I-CSCF (I-CSCF-CDR) 38 

5.2.3.4 Charging Data in MRFC (MRFC-CDR) 39 

5.2.3.5 Charging Data in MGCF (MGCF-CDR) 40 



£75/ 



3GPP TS 32.225 version 5.1 .0 Release 5 4 ETSI TS 1 32 225 V5.1 .0 (2002-1 2) 

5.2.3.6 Charging Data in BGCF (BGCF-CDR) 41 

5.2.3.7 Charging Data in AS (AS-CDR) 42 

5.2.4 CDR Parameter Description 42 

5.2.4.1 Authorised QoS 42 

5.2.4.2 Bearer Service 42 

5.2.4.3 Called Party Address (Public User ID) 43 

5.2.4.4 Calling Party Address (Public User ID) 43 

5.2.4.5 Cause 43 

5.2.4.6 Cause for Record Closure 43 

5.2.4.7 Event Type 43 

5.2.4.8 GGSN Address 43 

5.2.4.9 GPRS Charging ID 43 

5.2.4.10 IMS Charging Identifier (ICID) 43 

5.2.4.11 Inter Operator Identifier(s) 45 

5.2.4.12 List of AS Involved 45 

5.2.4.13 List of AS Provided Called Party Address 45 

5.2.4.14 List of Session Modifications 45 

5.2.4.15 Local Record Sequence Number 46 

5.2.4.16 Media Initiator Flag 46 

5.2.4.17 Node Address 46 

5.2.4.18 Partial Record Sequence Number 46 

5.2.4.19 Private User ID (served party) 46 

5.2.4.20 Record Closure Time 47 

5.2.4.21 Record Extensions 47 

5.2.4.22 Record Opening Time 47 

5.2.4.23 Record Type 47 

5.2.4.24 Retransmission 47 

5.2.4.25 Role of Node 47 

5.2.4.26 SDP Media Component 47 

5.2.4.27 SDP Session Description 47 

5.2.4.28 Service ID 47 

5.2.4.29 Service Specific Data 47 

5.2.4.30 Session ID 47 

5.2.4.31 Served party IP Address 47 

5.2.4.32 SIP Request Timestamp 47 

5.2.4.33 SIP Response Timestamp 47 

5.2.4.34 S-CSCF Information 48 

5.2.4.35 Trunk Group ID Incoming/Outgoing 48 

5.2.4.36 User-to-User Data 48 

5.2.5 Bi interface Conventions 48 

5.2.6 Abstract Syntax Description 48 

5.2.7 Data Encoding Rules 48 

6 Online Charging 48 

6.1 Diameter Description on the Ro Interface 48 

6.1.1 Basic Principles 48 

6.1.2 Message Flows and Types 49 

6.1.2.1 Immediate Event Charging (lEC) 49 

6.1.2.1.1 Message Flows - Successful Cases and Scenarios 49 

6.1.2.1.2 Message Flows - Error Cases and Scenarios 50 

6.1.2.2 Event Charging with Unit Reservation (ECUR) 50 

6.1.2.2.1 Message Flows - Successful Cases and Scenarios 50 

6.1.2.2.2 Message Flows - Error Cases and Scenarios 54 

6.1.3 Message Formats 55 

6.1.3.1 Summary of Online Charging Message Formats 55 

6.1.3.2 Structure for the Accounting Message Formats 55 

6.1.3.2.1 Accounting-Request Message 56 

6.1.3.2.2 Accounting-Answer Message 57 

6.1.3.3 Detailed Message Formats 57 

7 AVPs Used for Offline and Online Charging 59 

7.1 Diameter Base Protocol AVPs 59 



£75/ 



3GPP TS 32.225 version 5.1 .0 Release 5 5 ETSI TS 1 32 225 V5.1 .0 (2002-1 2) 

7.1.1 Result-Code AVP 60 

7.1.2 User-Name AVP 61 

7.1.3 Vendor-Specific-Application-Id AVP 61 

7.2 Additional AVPs 61 

7.2.1 Amount-of-UUS-Data AVP 62 

7.2.2 Application-Provided-Called-Party-Address AVP 63 

7.2.3 Application-Server AVP 63 

7.2.4 Authorised-QoS AVP 63 

7.2.5 Bearer-Service AVP 63 

7.2.6 Called-Party-Address AVP 63 

7.2.7 Calling-Party-Address AVP 63 

7.2.8 Content-Disposition AVP 63 

7.2.9 Content-Length AVP 63 

7.2.10 Content-Type AVP 63 

7.2.11 Cost-Information AVP 63 

7.2.12 Direction AVP 64 

7.2.13 Event AVP 64 

7.2.14 Event-Type AVP 64 

7.2.15 GGSN-Address AVP 64 

7.2.16 GPRS-Charging-ID AVP 64 

7.2.17 Granted-Service-Unit AVP 65 

7.2.18 IMS-Charging-ldentifier (ICID) AVP 65 

7.2.19 Incoming-Trunk-Group-ID AVP 65 

7.2.20 Inter-Operator-ldentifier (lOl) AVP 65 

7.2.21 Mime-Type AVP 65 

7.2.22 Originating-lOl AVP 65 

7.2.23 Outgoing-Trunk-Group-ID AVP 65 

7.2.24 Role-of^Node AVP 66 

7.2.25 SDP-Media-Component AVP 66 

7.2.26 SDP-Media-Description AVP 66 

7.2.27 SDP-Media-Name AVP 66 

7.2.28 SDP-Session-Description AVP 66 

7.2.29 Served-Party-IP-Address AVP 66 

7.2.30 Service-ID AVP 66 

7.2.31 SIP-Method AVP 66 

7.2.32 SIP-Request-Timestamp AVP 67 

7.2.33 SIP-Response-Timestamp AVP 67 

7.3.34 Tariff-Switch-Definition AVP 67 

7.2.35 Terminating-IOI AVP 67 

7.2.36 Time-Stamps AVP 67 

7.2.37 Trunk-Group-ID AVP 67 

7.2.38 Unit-Type AVP 68 

7.2.39 Unit-Value AVP 68 

7.3.40 Unit-Value-After-Tariff-Switch AVP 69 

7.2.41 Used-Service-Unit AVP 69 

7.2.42 User-Session-ID AVP 70 

7.2.43 UUS-DataAVP 70 

Annex A (informative): Change history 71 

History 72 



£75/ 



3GPP TS 32.225 version 5.1 .0 Release 5 6 ETSI TS 1 32 225 V5.1 .0 (2002-1 2) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document covers both onHne and offline charging for the IMS. For clarity, the terms Offline Charging and 
Online charging as applied to the IMS are defined here in clause 3. These definitions are the same as listed in 
TS 32.200 [2]. 

The IMS charging architecture details, requirements, definitions and principles are listed in TS 32.200 [2] and therefore 
are not repeated here. 

In the present document the charging data triggers, message content and format are specified along with the transport of 
these messages using the Diameter protocol. Details about charging message flows and the definitions of the Diameter 
AVPs are also included in the present document. This information is divided into two main clauses: Online Charging 
and Offline Charging. 



2 References 

The following documents contain provisions, which through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulai-y for 3GPP Specifications". 

[2] 3GPP TS 32.200: "Telecommunication management; Charging management; Charging 

principles". 

[3] IETF Internet-Draft, "Diameter Base Protocol". 

http://www.ietf org/internet-drafts/draft-ietf-aaa-diameter- 12.txt 

NOTE: The above reference will need to be updated to reference the assigned RFC number, once the draft 
achieves RFC status within the IETF. 

[4] 3GPP TS 33.201: "Access domain security". 

[5] 3GPP TS 23.218: "IP Multimedia (IM) session handUng; IM call model; Stage 2". 

[6] IETF RFC 2486: "The Network Access Identifier". 

[7] 3GPP TS 23.207: "End to end quality of service concept and architecture". 

[8] 3GPP TS 29.207: "Policy control over Go interface". 

[9] ITU-T Recommendation X.690: "Information technology - ASN.l encoding rules: Specification of 

Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding 
Rules (DER)". 

[10] ITU-T Recommendation X.691: "Information technology - ASN.l encoding rules: Specification of 

Packed Encoding Rules (PER)". 

[II] ITU-T Recommendation X.693: "Information Technology - ASN.l encoding rules: XML 
encoding Rules (XER)". 

[12] 3GPP TS 24.228: "SignalHng flows for the IP multimedia call control based on SIP and SDP; 

Stage 3". 
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[13] IETF Internet-Draft, "Diameter Credit Control Application". 

http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-Q4.txt 

NOTE: The above reference will need to be updated to reference the assigned RFC number, once the draft 
achieves RFC status within the IETF. 

[14] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3." 

[15] IETF Internet-Draft, "Private Extensions to the Session Initiation Protocol (SIP) for the 3"" 

Generation Partnership Projects (3GPP)". 
http://www.ietf org/internet-drafts/draft-garcia-sipping-3gpp-p-headers-01.txt 

NOTE: The above reference will need to be updated to reference the assigned RFC number, once the draft 
achieves RFC status within the IETF. 

[16] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[17] IETF Internet-Draft, "SDP: Session Description Protocol". 

http://www.ietf org/internet-drafts/draft-ietf-mmusic-sdp-new- 10. txt 

NOTE: The above reference will need to be updated to reference the assigned RFC number, once the draft 
achieves RFC status within the IETF. 

[18] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[19] 3GPP TS 29.229: "Cx and Dx Interfaces based on the Diameter protocol; Protocol Details". 



Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of th present document, the following terms and definitions apply: 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



Bi 
Rb 
Re 
Re 
Rf 
Ro 



The Interface between the IMS charging function and the BS 

Online Charging Reference Point between Session Charging Function and Correlation Function 

Online Charging Reference Point between ECF and Correlation Function 

Online Charging Reference Point towards a Rating Server 

Offline Charging Reference Point between an IMS Network Entity or an AS and CCF 

Online Charging Reference Point between an AS or MRFC and the ECF 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations defined in TR 21.905 [1], TS 32.200 [2] and the following 
apply: 



ABNF 

ACA 

ACR 

AS 

ASA 

ASR 



Augmented Backus-Naur Form 
Accounting Answer 
Accounting Request 
Application Server 
Abort Session Answer 
Abort Session Request 
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AVP Attribute Value Pair 

B2BUA Back-to-Back User Agent 

BGCF Breakout Gateway Control Function 

BS Billing System 

CCF Charging Collection Function 

CDR Charging Data Record 

CPCF Content Provider Charging Function 

ECF Event Charging Function 

ECUR Event Charging with Unit Reservation 

CSCF Call Session Control Function (I-Interrogating; P-Proxy; and S-Serving) 

lEC Immediate Event Charging 

IMS IP Multimedia Subsystem 

ISC IMS Service Control 

MGCF Media Gateway Control Function 

MRFC Media Resource Function Controller 

MRFP Multimedia Resource Function Processor 

OCS Online Charging System 

SCCF Subscriber Content Charging Function 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UA User Agent 

UE User Equipment 



4 Offline and Online Charging 

4.1 Implementation of Offline and Online Charging 

The IMS charging architecture, described in TS 32.200 [2], specifies that for offline charging all communications 
between the IMS network entities and the CCF are carried out on the Rf interface. On the other hand, for online 
charging the Ro interface is used by the AS and MRFC towards the Event Charging Function and the ISC interface is 
used between the S-CSCF and the Session Charging Function. The rules governing the selection of the proper interfaces 
are described in the subclauses below. 

4.1 .1 Usage of Rf and Ro Interfaces 

The AS and MRFC are able to distinguish whether to apply offline or online charging, i.e. whether to send charging 
information on the Rf interface to the CCF or on the Ro interface to the ECF (or to use both). The decision of which 
interface to use is based on the information (CCF and/or ECF address) the AS/MRFC receive in the SIP signaling and 
the system configuration as provisioned by the operator. If the AS/MRFC only receive the CCF address and do not 
receive an ECF address then they use only the Rf interface. If only the ECF address was provided then they use only the 
Ro interface. In cases where both CCF and ECF addresses are provided it is possible to use both interfaces 
simultaneously. 

However, operators may overrule the addresses received via the SIP signalling and use their own configured rules 
instead. Operators may configure locally on the AS/MRFC an ECF and/or CCF address. The CCF address may be 
locally configured on all other IMS nodes. The choice of whether the IMS nodes use the locally configured addresses or 
the addresses received by SIP signalling, and the decision on which interface(s) to use, is left for operator configuration. 



4.1 .2 Usage of Rf and ISC Interfaces 



All other IMS nodes (S-CSCF, P-CSCF, I-CSCF, BGCF and MGCF) apply offline charging via the Rf interface using 
the CCF address as received via SIP signaling or the locally configured CCF address. The S-CSCF supports online 
charging using the ISC interface, i.e. if the application server addressed over ISC is the Session Charging Function of 
the OCS. 
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4.1 .3 Support of Local File Storage 



The present document does not mandate the support of persistent storage on the IMS nodes nor does it require any 
protocol except Diameter to be used for either onHne or offline charging. However, if an IMS node supports a local 
persistent storage media, it should be able to store the accounting information as contained in the Diameter messages on 
this local filestore. Operator's post-processing systems may then collect the contents of the filestore (e.g. via FTP) 
applying the same file transfer procedures as those that are used when accessing the Bi interface at the CCF. 

4.2 Diameter Protocol Basic Principles and Use 

The present document defines a 3GPP IMS charging Diameter application, which utilizes the Diameter Base Protocol 
[3]. This application is used for both online and offline charging. The generic description of the protocol is provided in 
the subclauses below while the portions of the protocol application associated with offline and online charging are 
described in clauses 5 and 6, respectively. 

4.2.1 Basic Principles 

The IMS charging Diameter application is based on the following general principles: 

• The basic functionality of Diameter, as defined by the Diameter Base Protocol [3] is re-used in IMS. 

• For offline charging IMS network elements report accounting information to the Charging Collection Function 
(CCF). The CCF uses this information to construct and format CDRs. 

• For online charging, the AS and MRFC in the IMS network report accounting information to the Event Charging 
Function (ECF). The ECF uses this information to support the event based charging (content charging) function 
oftheOCS. 

4.2.2 Application Requirement for the Base Protocol 

4.2.2.1 Offline Specific Base Protocol Requirements 

In order to support the offline charging principles described in the present document, the Diameter client and server 
must implement at least the following Diameter options listed in [3]: 

• To send/receive Abort-Session-Request. 

• To send/receive Abort-Session-Answer. 

All other options of the Diameter Base Protocol are beyond the scope of the present document. 

\f Acct-Interim-Interval AVP is not used or its value field is set to 0, the timer Ts should have a configurable default 
value. 

For offline charging, the client implements the state machine described in [3]. The server (CCF) implements the 
STATELESS ACCOUNTING state machine as specified in [3], i.e. there is no order in which the server expects to 
receive the accounting information. 

4.2.2.2 Online Specific Base Protocol Requirements 

If Acct-Inte rim-Interval AVP is not used or its value field is set to 0, the timer Ts should have a configurable default 
value. 

The online cHent (e.g. AS, MRFC) implements the state machine described in [13] for "CLIENT, EVENT BASED" or 
"CLIENT, SESSION BASED", i.e. when the client applies Immediate Event Charging (lEC) it uses the "CLIENT, 
EVENT BASED" state machine, or when the client applies Event Charging with Unit Reservation (ECUR) it uses the 
"CLIENT, SESSION BASED" state machine. 

The online charging server that is part of the OCS implements the state machine described in [13] for the "SERVER, 
SESSION AND EVENT BASED" in order to support Immediate Event Charging and Event Charging with Unit 
Reservation. 



£75/ 



3GPP TS 32.225 version 5.1.0 Release 5 



11 



ETSI TS 132 225 V5.1.0 (2002-12) 



4.2.2.3 Security Considerations 

Diameter security is addressed in the base protocol [3]. Network security is specified in TS 33.201 [4]. 

5 Offline Charging 

5.1 Diameter Description on the Rf Interfaces 



5.1.1 



Basic Principles 



The offline charging functionality is based on the IMS network nodes reporting accounting information upon reception 
of various SIP methods or ISUP messages, as most of the accounting relevant information is contained in these 
messages. This reporting is achieved by sending Diameter Accounting Requests (ACR) [Start, Interim, Stop and Event] 
from the IMS nodes to the CCF and/or ECF. 

The Diameter client uses ACR Start, Interim and Stop in procedures related to successful SIP sessions. It uses ACR 
Events for unsuccessful SIP sessions and for session unrelated procedures. Further details are specified in the tables 
below and in subclause 5.1.2. 

It is operator configurable in the nodes for which SIP method or ISUP messages an Accounting Request is sent, with the 
exception that if accounting information is collected for sessions the ACR [Start] and ACR [Stop] messages are 
mandatory according to the tables below. Table 5.1 describes all possible ACRs that might be sent from a P-CSCF, 
I-CSCF, S-CSCF, MGCF or BGCF. A list of node specific ACRs, along with the AVPs to be included are detailed in 
section 5.1.3.3. 

The ACRs to be sent from a MRFC are described in table 5.2. 

In the tables below, the terms "configurable" implies that operators may enable or disable the generation of an ACR 
message by the IMS node in response to a particular "Triggering SIP Method /ISUP Message". However, for those table 
entries marked with *, the operator can enable or disable the ACR message based on whether or not the SIP (Re) Invite 
message that is replied to by the "Triggering SIP Method /ISUP Message" carried piggybacked user data. 

Table 5.1 : Accounting Request Messages Triggered by SIP Methods or ISUP Messages 
for all IMS nodes except for MRFC and AS 



Diameter Message 


Triggering SIP Method /ISUP Message 


Mandatory/Configurable 


ACR [Start] 


SIP 200 OK acknowledging an initial SIP INVITE 


Mandatory 


ISUP:ANM (applicable for the MGCF) 


Mandatory 


ACR [Interim] 


SIP 200 OK acknowledging a SIP 
RE-INVITE [e.g. change in media components] 


Configurable 


Expiration of AVP [Acct-lnterim-lnterval] 


Configurable 


ACR [Stop] 


SIP BYE message 


Mandatory 


SIP Final Response with error codes 4xx, 5xx or 6xx, indicating 
termination of an ongoing session 


Mandatory 


ISUP:REL (applicable for the MGCF) 


Mandatory 


ACR [Event] 


SIP 200 OK acknowledging non-session related SIP messages, 
which are: 

SIP NOTIFY 

SIP MESSAGE 

SIP REGISTER 

SIP SUBSCRIBE 


Configurable 
Configurable 
Configurable 
Configurable 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP 
session set-up 


Configurable * 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful 
session-unrelated procedure 


Configurable * 


SIP CANCEL, indicating abortion of a SIP session set-up 


Configurable * 


I-CSCF completing a Cx Ouery that was issued in response to a SIP 
INVITE 


Configurable 
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NOTE: SIP SUBSCRIBE with the field "Expires" set to means unsubscribe. SIP REGISTER with its "Expires" 
header field or "Expires" parameter equal to means Deregistration [14]. 

Table 5.2: Accounting Request Messages Triggered by SIP Methods for the MRFC 



Diameter Message 


Trigger 


Mandatory/Configurable 


ACR [Start] 


SIP 200 OK acknowledging an SIP INVITE for initiating a multimedia 
ad hoc conferencing session 


IVIandatory 


ACR [Interim] 


SIP ACK acknowledging a SIP INVITE to connect an UE to the 
conferencing session 


Configurable 


Expiration of AVP [Acct-lnterim-lnterval] 


Configurable 


ACR [Stop] 


SIP BYE message 


Mandatory 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating 
termination of an ongoing session 


Mandatory 



ASs support all four ACR types (Start/Interim/Stop/Event). The use of ACR Start, Interim and Stop (Session Charging) 
versus ACR Event (Event Charging) depends on the services provided by the application server. Example flows for an 
AS employing Event Charging and an AS using Session Charging are shown in subclause 5.1.2.1.3. 

The ability of SIP methods not listed in tables 5.1 and 5.2 to trigger ACRs is for further study. 

5.1 .2 Message Flows and Types 

The flows described in the present document specify the charging communications between IMS entities and the 
charging functions for different charging scenarios. The SIP messages associated with these charging scenarios are 
shown primarily for general information and to illustrate the charging triggers. They are not intended to be exhaustive 
of all the SIP message flows discussed in TS 24.228 [12]. 

5.1 .2.1 Message Flows - Successful Cases and Scenarios 

5.1.2.1.1 Session Related Procedures 



5.1.2.1.1.1 



Session Establishment - Mobile Origination 



Figure 5.1 shows the Diameter transactions that are required between CSCF and CCF during session establishment 
originated by a UE. 
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Visited Network 



Home Network 



UE 



1. INVITE 




2. 200 OK 




P-CSCF 



CCF 

(visited) 



1. INVITE 



S-CSCF 



CCF 

(home) 



Service Control 



1. INVITE 



More SIP signalling 



^ 



200 OK (Invite) 



5. Accounting Requ;st [Start] 



^ 



. 200 OK (Invite) 



Service Control 



Open a P-CSCF CDR 



6. Accounting Ansv 

K 



3. Accounting Request [Start] 




Open a S-CSCF CDR 



4. Accounting Answe: 

K 



More SIP signalling 




SIP Session established 



1. 

2. 
3. 



4. 
5. 
6. 



"1 I I I I 

Figure 5.1 : Message Sequence Chart for Session Establishment (Mobile Origination) 

The session is initiated. 

The destination party answers and a final response is received. 

Upon reception of the final response, the S-CSCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the S-CSCF CDR. 

The CCF acknowledges the reception of the data and opens a S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, but creating a P-CSCF CDR. 



5.1.2.1.1.2 



Session Establishment - Mobile Termination 



Figure 5.2 shows the Diameter transactions that are required between CSCF and CCF during a session establishment 
that is terminated to a mobile. The I-CSCF is only involved in the INVITE transaction. 
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Visited Network 



Home Network 



UE 



P-CSCF 




CCF 

(visited) 



S-CSCF 



CCF 

(home) 



I-CSCF 



Cx Query with the HSS 



2. Accounting Request 



Create 1-CSCFCDR 



Service Conti"ol 



3. Accounting Answer ^ 



More SIP signalling 



>. Accounting Reque^ 




IStartJ 



Open P-CSCF CDR 



6. Accounting Answei 



7. Accounting Reque ^ t [Start] 



Open S-CSCF CDR 



8. Accounting Answe 
A 



More SIP signalling 



[Event] 





SIP Session established 



Figure 5.2: Message Sequence Chart for Session Establishment (Mobile Termination) 



1. 

2. 

3. 
4. 
5. ■ 



The session is initiated. 

Upon completing a Cx query the I-CSCF sends an Accounting Request with the 

Accounting-Record-Type set to EVENT. 

The CCF acknowledges the data received and creates an I-CSCF CDR. 

The destination party answers and a final response is sent. 

These steps are identical to the corresponding steps described in subclause 5.1.2.1.1.1. 
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5.1.2.1.1.3 



Mid-Session Procedures 



Figure 5.3 shows the Diameter transactions that are required between CSCF and CCF when a UE generates a Re-Invite 
in mid-session, e.g. in order to modify media component(s), or when the hold and resume procedure is executed. 



Visited Networli 



Home Network 



CCF 

(visited) 



I 



S-CSCF 



CCF 

(home) 



SIP Session ongoing 



1. INVITE 

(Re-Invite) 




1. INVITE 

(Re- Invite) 



Service Control 



1. INVITE 

(Re-Invite) 



More SIP signalling 



2. 200OK(Re-Inviie) 



2. 200 OK (Re-Invite) 



5. Accounting Requ ist [Interim] 



. 200 OK (Re-Invitt ) 



Service Control 



Update the P-CSCF CDR 



6. Accounting Answejr 



3. Accounting Request [Interim] 




Update the S-CSCF CDR 



4. Accounting Answer 



SIP Session continues 



Figure 5.3: Message Sequence Chart for Media Modification 



1. 

2. 
3. 



4. 
5. 
6. 



Modified media information is received from the subscriber. 

The destination party acknowledges the media modification. 

At modification of a media, the S-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating INTERIM_RECORD to record modification of a media component in the S-CSCF 

CDR. 

The CCF acknowledges the reception of the data and updates the S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, updating the P-CSCF CDR. 
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5.1.2.1.1.4 



Session Release - Mobile Initiated 



Figure 5.4 shows the Diameter transactions that are required between CSCF and CCF for a session release that is 
initiated by the UE. 



UE 



Visited Network 



fi. 200 OK 



P-CSCF 



CCF 

(visited) 



l.BYE 



2. Accounting Req^e ^t [Stop] 



Close the P-CSCF CDR 



3. Accounting Answt r 



6. 200 OK 



Home Networli 



S-CSCF 



CCF 

(home) 



Service Control 



l.BYE 



4. Accounting Reque it [Stop] 



Close the S-CSCF CDR 



^. Accounting 



AnsW' :r 



6. 200 OK 



Figure 5.4: Message Sequence Chart for Session Release 



1. 

2. 



3. 
4. 
5. 
6. 



The session is released. 

At session termination the P-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating STOP_RECORD to record stop of a session and stop of a media component in the 

P-CSCF CDR. 

The CCF acknowledges the reception of the data and closes the P-CSCF CDR. 

Same as 2, but for S-CSCF. 

Same as 3, closing the S-CSCF CDR. 

The release is acknowledged. 



5.1.2.1.1.5 



Session Release - Network Initiated 



The message flow for this case is identical to the mobile initiated session release described in subclause 5.1.2.1.1.4. 
However, before invoking the procedure, the UE receives a command requesting session release from the network. 
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5.1.2.1.1.6 



Session Release - CCF initiated 



The IMS operator may request the release of SIP session(s) upon certain trigger conditions being met, for example as 
soon as a fraud is detected. The communication between CCF and external functions that convey that request to the 
CCF is not in the scope of the present document. 

Figure 5.5 shows the Diameter transactions that are required between CCF and S-CSCF in order to release an ongoing 
SIP session. 



UE 



Visited Network 



P-SCSF 



CCF 

(visited) 



Home Network 



S-CSCF 



CCF 

(iiome) 



SIP Session ongoing 



3. BYE 



. 200 OK 



4. Accounting Reqi est [Stop] 



3. BYE 



Close the P-CSCF CDR 



5. Accounting Answ 



9. 200 OK 



1. Abort Session Ret uest 



2. Abort Session An; wer 



3. BYE 



6. Accounting Request [Stop] 




Figure 5.5: Message Sequence Chart for CCF Initiated Session Release 

1 . The CCF may initiate the SIP session release by sending an Abort-Session-Request message to the 
S-CSCF. 

2. The S-CSCF acknowledges the Abort-Session-Request by sending an Abort-Session-Answer 
message to the CCF. Upon receiving the Abort-Session-Answer, the CCF closes the CDR. The 
record closure time in the CDR is the time when the Abort-Session-Answer message has been 
received. 

3. The S-CSCF initiates the SIP session release by sending SIP BYE request to both the originating 
and the terminating parties, as specified in TS 23.218 [5]. 

4. At session termination the P-CSCF sends Accounting-Request with Accounting-Record-Type 
indicating STOP_RECORD to record stop of a session and stop of a media component in the 
P-CSCF CDR. 

5. The CCF acknowledges the reception of the data and closes the P-CSCF CDR CDR. 

6. Same as 4, but for S-CSCF. 

7. Same as 5, but for S-CSCF CDR. 

8. - 10. The S-CSCF receives the 200 OK responses from originating and terminating parties. 

The S-CSCF should not be restricted to receiving Abort Session Requests only from a CCF, since such requests may be 
sent to an S-CSCF from other (i.e. non-IMS) sources, e.g. an operator's fraud detection system. 
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5.1.2.1.2 



Session-Unrelated Procedures 



Figure 5.6 shows the Diameter transactions that are required between CSCF and CCF for session-unrelated IMS 
procedures, i.e. those that relate to the Diameter ACR [Event], as listed in table 5.1. 



visited Network 



Home Network 



UE 




P-CSCF 



1. SIP Request (e.g. 

> 



2. SIP Response 



CCF 

(visited) 



SUBSCRIBE) 
1 . SIP Request (e.g. 



S-CSCF 



SUBSCRIBE) 



CCF 

(iiome) 



Service Control 



More SIP signalling 



2. SIP Response 



5. Accounting Requi st [Event] 



Req\jt 



Create P-CSCF CDR 



6. Accounting Answer 



3. Accounting Request [Event] 




Create S-CSCF CDR 



4. Accounting AnsW' '.r 



Figure 5.6: Message Sequence Chart for Session-Unrelated Procedure 



1. 

2. 



The P-CSCF receives a "SIP Request" (e.g. SUBSCRIBE) from the subscriber. 
The "SIP Request" is acknowledged by the "SIP Response" as follows: 

in the successful case, a 200 OK message is returned; 

in case of failure an appropriate SIP error message is returned. 



Depending on the used SIP method, there might be additional signalling between steps 1 and 2. 



3. 



4. 
5. 
6. 



After the completion of the procedure, the S-CSCF sends Accounting-Request with Accounting- 
Record-Type indicating EVENT_RECORD to record transaction specific information in the 
S-CSCF CDR. 

The CCF acknowledges the reception of the data and produces an S-CSCF CDR. 
Same as 3, but for P-CSCF. 
Same as 4, creating a P-CSCF CDR. 
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5.1.2.1.3 



PSTN Related Procedures 



5.1.2.1.3.1 



Session Establishment - PSTN Initiated 



Figure 5.7 shows the Diameter transactions that are required between MGCF and CCF during session establishment 
initiated from the PSTN side. 



PSTN 



l.IAM 



4. ANM 



Home Network 



MGCF 



CCF 

(home) 



2. INVITE 



More SIP/ISUP signalling 



3. 200 OK (Invite) 



5. Accounting Request [Start] 



Open a MGCF CDR 



6. Accounting Answer 



More SIP signalling 



Session established 



Figure 5.7: Message Sequence Chart for Session Establishment (PSTN Initiated) 



1. 

2. 
3. 
4. 
5. 



6. 



The session is originated from the PSTN. 

The session setup is triggered in the IMS. 

The destination party answers and a final response is received. 

MGCF forwards an answer message to the PSTN. 

Upon reception of the final response, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the MGCF CDR. 

The CCF acknowledges the reception of the data and opens a MGCF CDR. 
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5.1.2.1.3.2 



Session Establishment - IMS Initiated 



Figure 5.8 shows the Diameter transactions that are required between BGCF, MGCP and CCF during session 
estabUshment initiated from the IMS side. 



Home Network 




Figure 5.8: Message Sequence Chart for Session Establishment (IMS Initiated) 



1. 

2. 
3. 
4. 
5. 



6. 

7. 



The session is originated from the IMS. 

A session towards PSTN is established. 

The destination party answers and an answer message is received. 

A final response message is sent to the session originator. 

Upon reception of the answer message, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the MGCF CDR. 

The CCF acknowledges the reception of the data and opens a MGCF CDR. 

Upon reception of the 200 OK message, the BGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the BGCF CDR. 

The CCF acknowledges the reception of the data and opens a BGCF CDR. 
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5.1.2.1.3.3 



Session Release - PSTN Initiated 



Figure 5.9 shows the Diameter transactions that are required between BGCF, MGCP and CCF during a PSTN initiated 
session release. The BGCF is only involved if the session had been initiated from the IMS side. 



Home Network 



BGCF 



2. BYE 



MGCF 



CCF 



Session ongoing 



2. BYE 



6. Accounting Request [St( 



7. Accounting Answer 



l.REL 



3.RLC 



4. Accounting Request [Stop] 



PSTN 



Close the MGCF CDR 



^ 



Accounting Answer 



)P] 



Close BGCF CDR 



Figure 5.9: Message Sequence Chart for Session Release (PSTN initiated) 



1. 

2. 
3. 
4. 



5. 
6. 

7. 



The session release is initiated from PSTN. 

Session release continues within IMS. 

The reception of the release message is acknowledged. 

Upon reception of the release message, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating STOP_RECORD to record stop of a session in the MGCF 

CDR. 

The CCF acknowledges the reception of the data and closes the MGCF CDR. 

Same as 4, but for BGCF. 

Same as 5, but for BGCF. 
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5.1.2.1.3.4 



Session Release - IMS Initiated 



Figure 5.10 shows the Diameter transactions that are required between BGCF, MGCP and CCF during a IMS initiated 
session release. 

The BGCF is only involved if the session had been initiated from the IMS side. 

Home Network 



BGCF 



MGCF 



CCF 



PSTN 



Session ongoing 



l.BYE 



l.BYE 



4. Accounting Request [Sti 



'P] 



I J. Accounting Answer 



2. REL 



3.RLC 



Close BGCF CDR 



6. Accounting Request [Stop] 



Close the MGCF CDR 



7. Accounting Answer 



Figure 5.10: Message Sequence Chart for Session Release (IMS initiated) 



1. 

2. 
3. 
4. 



5. 
6. 

7. 



The session release is initiated from the IMS side. 

A release message is sent towards PSTN. 

The acknowledgement of the release message is received from PSTN. 

Upon reception of the BYE message, the BGCF sends an Accounting-Request with 

Accounting-Record-Type indicating STOP_RECORD to record stop of a session in the BGCF 

CDR. 

The CCF acknowledges the reception of the data and closes the BGCF CDR. 

Same as 4, but for MGCF. 

Same as 5, but for MGCF. 



5.1.2.1.4 



MRFC Related Procedures 



5.1.2.1.4.1 



Multi-Party Call 



Figure 5.11 shows the establishment of an ad hoc conference (multiparty call). An AS (acting as B2BUA) performs 
third party call control with the MRFC, where the S-CSCF is in the signalling path. The Application Server that is in 
control of the ad hoc conference is aware of the MRFC capabilities. 

NOTE: Only accounting information sent from the MRFC is shown in detail in the figure. The SIP messages are 
for illustrative purpose only. 
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Home Network 



AS 



1. INVITE (MPTY) 



S-CSCF 



1. INVITE (MPTY) 



Service logic 



2. INVITE 



3. 200 OK 



CCF 

(liome) 



2. INVITE 



3. 200 OK 



MRFC 



4. Accounting Request 



Open an MRFC CDR 



5. Accounting Answer 



[Start] 



Establish path between UE-2 and MRFP. 



6. ACK 



9. INVITE 



10. 200 OK 



6. ACK 



, 7. Accounting Request 



Update the MRFC CDR 



9. INVITE 



10. 2(X) OK 



8. Accounting Answer 



[Interim] 



Establish path between UE-3 and MRFP. 



11. ACK 



14. INVITE 



15. 200 OK 



11. ACK 



12. Accounting Request 



Update the MRFC CDR 



14. INVITE 



15. 200 OK 



13. Accounting Answer 



[Interim] 



Establish path between UE-1 and MRFP. 



16. ACK 



16. ACK 



J7. Accounting Request 



Update the MRFC CDR 



18. Accounting Answer 

>^ 



[Interim] 



Figure 5.11 : Message Sequence Chart for Multi-Party Call Establishment in MRFC 
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I. Sessions exist between UE-1 and UE-2, and between UE-1 and UE-3. A request is received from 
UE-lfor putting all parties together to a multi -party call. 

2.-3. Request and acknowledgement to initiate multi -party call. 

4. At session establishment the MRFC sends an Accounting-Request with Accounting-Record-Type 
indicating START_RECORD to record start of multi-party call in the MRFC CDR 

5. The CCF acknowledges the reception of the data and creates the MRFC CDR. 

6. Dialog between UE-2 and MRFP has been established. 

7. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-2 has been connected to the multi-party call. 

8. The CCF acknowledges the reception of the data and updates the MRFC CDR. 

9. New request sent to MRFC to prepare dialog for UE-3. 

10. Request acknowledged. 

I I . Dialog between UE-3 and MRFP has been established. 

12. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-3 has been connected to the multi-party call. 

13. The CCF acknowledges the reception of the data and updates the MRFC CDR. 

14. New request sent to MRFC to prepare dialog for UE-1 . 

15. Request acknowledged. 

16. Dialog between UE-1 and MRFP has been established. 

17. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-1 has been connected to the multi -party call. 

18. The CCF acknowledges the reception of the data and updates the MRFC CDR. 

5.1.2.1.5 AS Related Procedures 

Application servers may support a multitude of services which are not specified in 3GPP standards. Therefore it is not 
possible to standardise charging flows and procedures for those services. However, for all such services, the AS may 
apply either Event Charging, where ACR [Event] messages are generated, or Session Charging, using ACR [Start, Stop 
and Interim]. The following subclauses depict one example for each of the two scenarios. The first procedure, AS acting 
as a Redirect Server, depicts the "event" case, while the second procedure, AS acting as a Voice Mail Server, depicts the 
"session" case. 

5.1 .2.1 .5.1 AS Acting as a Redirect Server 

Figure 5.12 shows the case where an Application Server acts as a Redirect Server. In the figure below, UE-1 sets up a 
session towards UE-2 but due to Call Forwarding functionality located in the AS, a new number (to UE-3) is returned to 
UE-1. Finally UE-1 sets up the session towards UE-3. 
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Originating UE-l 
home network 



1. INVITE 



Terminating UE-2 Home Network 



S-CSCF 



AS 



Service control 



6. 302 MOVED TEMPOR. \.RILY 



7. ACK 



. INVITE 



1. INVITE 



Application performs 
number translation 



2. 302 MOVED TEMPORARILY 



3. ACK 



Terminating UE-3 
home network 



CCF 

(home) 



4. Accounting Request [Eve 



It] 



Create an AS CDR 



^ 



Accounting Answer 



Setting up session towards UE-3 



Figure 5.12: Message Sequence Chart for AS Acting as a Redirect Server 



1. 

2.-3. 
4. 



5. 
6-7. 



Sessions initiated by UE-l towards UE-2. 

Response indicating that session should be redirected towards another number (UE-3). 

After successful service execution, the AS sends Accounting-Request with 

Accounting-Record-Type indicating EVENT_RECORD to record service specific information in 

the AS CDR. 

The CCF acknowledges the reception of the data and creates the AS CDR. 

Response indicating that session should be redirected towards another number (UE-3). 

Session is initiated by UE-l towards UE-3. 



5.1.2.1.5.2 



AS Acting as a Voice Mail Server 



Figure 5.13 shows the case where an Application Server acts as a Voice Mail Server. S-CSCF invokes the AS acting as 
Voice Mail Server according to procedure as defined in TS 23.218 [5]. 
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S-CSCF 



AS (Voice 
Mail) 



CCF 



SIP signalling 



1. Invite 



Voice mail service invoked. 



2. 200 OK (Invite) 



3. Accounting Request [Start] 



Open an AS CDR 



4. Accounting Answer 



Voice mail session (playing announcements, etc.). . . When voice mail ends, tearing down session 



5. BYE 



6. Accounting Request [Step] 



Close the AS CDR 



7. Accounting Answer 



Figure 5.13: Message Sequence Chart for AS Acting as a IVIail Server 

1 . AS receives the INVITE from the S -CSCF. 

2. AS acknowledges the initiated Voice Mail session by issuing a 200 OK in response to the INVITE. 

3. AS sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start 
of a voice mail session. 

4. The CCF acknowledges the reception of the Accounting-Request with Accounting-Record-Type indicating 
START_RECORD and opens a AS CDR. 

5. Voice mail session release is initiated. 

6. Upon reception of release message AS sends an Accounting-Request with Accounting-Record-Type 
indicating STOP_RECORD to record stop of a session in the AS CDR. 

7. The CCF acknowledges the reception of the data and closes the AS CDR. 
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5.1 .2.2 Message Flows - Error Cases and Scenarios 

This subclause describes various error cases and how these should be handled. The error cases are grouped into the 
following categories: 

• Failure in SIP Related Procedures: 

Session Related Error Scenarios; 
Session Unrelated Error Scenarios. 

• Errors in Diameter (Accounting) Related Procedures. 

5.1 .2.2.1 Error Cases - Session Related SIP Procedures 

5.1 .2.2.1 .1 Reception of SIP error messages 

Normally a SIP session is closed by the reception of the BYE message. There are, however, a few cases when no BYE 
message is received and the ACR [Stop] message must be triggered by the reception of other messages. 

ACR [Stop] can also be triggered by the reception of a SIP Final Response with error codes 4xx, 5xx or 6xx, indicating 
termination of an ongoing session as described in [16]. 

NOTE: This also covers the error handling in originating procedures, as a CANCEL request sent by the 

originating party to cancel a session invitation will trigger the terminating party to reply with a 487 final 
response to the INVITE. 

The ACR [Stop] message includes an appropriate error indication. 

5.1.2.2.1.2 SIP session failure 

All nodes involved in the SIP session are expected to exercise some kind of session supervision. In case a node detects 
an error in the SIP session, such as a timeout or the occurrence of an invalid SIP message that results in the inability to 
maintain the session, this IMS node will generate a BYE message towards both ends of the connection. 

The node that sent the BYE to trigger session termination identifies the cause of the failure in the ACR [Stop] towards 
the CCF. All other nodes, i.e. those that receive the BYE, are not aware of an error, and therefore they treat this 
situation as any normal SIP session termination. 

5.1 .2.2.2 Error Cases - Session Unrelated SIP procedures 

As described in subclause 5. 1 .2. 1 .2, a session unrelated SIP procedure may either be completed with the reception of a 
200OK, or a SIP error message. If the latter occurs, i.e. there is a failure in the procedure, the ACR [Event] sent towards 
the CCF includes an appropriate error indication. 

5.1 .2.2.3 Error Cases - Diameter procedures 

5.1 .2.2.3.1 CCF Connection Failure 

When the connection towards the primary CCF is broken, the process of sending accounting information should 
continue towards a secondary CCF (if such a CCF is configured). For further CCF connection failure functionality, see 
subclause "Transport Failure Detection" in [3]. 

If no CCF is reachable the network element may buffer the generated accounting data in non- volatile memory. Once the 
CCF connection is working again, all accounting messages stored in the buffer is sent to the CCF, in the order they were 
stored in the buffer. 
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5.1.2.2.3.2 



No Reply from CCF 



In case an IMS node does not receive an ACA in reply to an ACR, it may repeat the ACR message. The waiting time 
until a repetition is sent, and the maximum number of repetitions are both configurable by the operator. When the 
maximum number of repetitions is reached and still no ACA reply has been received, the IMS node executes the CCF 
connection failure procedure as specified above. 

If retransmitted ACRs are sent, they are marked with the Re-Transmission AVP, in order to allow duplicate detection in 
the CCF, as specified in the next subclause. 



5.1.2.2.3.3 



Duplicate Detection 



A Diameter client marks possible duplicate request messages (e.g. retransmission due to the link failover process) with 
the Re-Transmission AVP. 

If the CCF receives a message that is marked as retransmitted and this message was already received, then it discards 
the duplicate message. However, if the original of the re-transmitted message was not yet received, it is the information 
in the marked message that is taken into account when generating the CDR. The CDRs are marked if information from 
duplicated message(s) is used. 



5.1.2.2.3.4 



CCF Detected Failure 



The CCF closes a CDR when it detects that expected Diameter ACRs for a particular SIP session have not been 
received for a period of time. The exact behaviour of the CCF is operator configurable. 

5.1.3 Message Formats 



5.1.3.1 



Summary of Offline Charging Message Formats 



The IMS nodes generate accounting information that can be transferred from the nodes to the CCF. For this purpose, the 
IMS Charging application employs the Accounting-Request and Accounting-Answer messages from the base Diameter 
protocol. 

The CCF may send an unsolicited message indicating to the S-CSCF to release the ongoing SIP session due for example 
to fraud detection. For this purpose the IMS Charging application employs the Abort-Session-Request and 
Abort-Session-Answer messages from the base Diameter protocol. 

Table 5.3 describes the use of these messages for offline charging. 

Table 5.3: Offline Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Abbreviation 


Accounting-Request 


S-CSCF, l-CSCF, P-CSCF, 
MRFC, MGCF, BGCF, AS 


CCF 


ACR 


Accounting-Answer 


CCF 


S-CSCF, l-CSCF, P-CSCF, 
MRFC, MGCF, BGCF, AS 


ACA 


Abort-Session-Request 


CCF 


S-CSCF 


ASR 


Abort-Session-Answer 


S-CSCF 


CCF 


ASA 



The S-CSCF should not be restricted to receiving Abort Session Requests only from a CCF, since such requests may be 
sent to an S-CSCF from other (i.e. non-IMS) sources, e.g. an operator's fraud detection system. 



5.1.3.2 



Structure for the Accounting- and Abort-Session Message Formats 



The following is the basic structure shared by all offline charging messages. This is based directly on the format of the 
Accounting-Request, Accounting-Answer, Abort-Session-Request and Abort-Session-Answer messages defined in the 
base Diameter protocol specification [3]. Detailed description of the AVPs and their use for offline and online charging 
are provided in clause 7. 



£75/ 



3GPP TS 32.225 version 5.1 .0 Release 5 29 ETSI TS 1 32 225 V5.1 .0 (2002-1 2) 

Those Diameter AVPs that are used for offline charging are marked "Yes" in tables 5.4 to 5.7. Those Diameter AVPs 
that are not used for offline charging are marked "No" in tables 5.4 to 5.7. This implies that their content can (Yes) or 
can not (No) be used by the CCF to construct CDRs. 

The following symbols (adopted from [3]) are used in the tables: 

• <AVP> indicates a mandatory AVP with a fixed position in the message. 

• {AVP} indicates a mandatory AVP in the message. 

• [AVP] indicates an optional AVP in the message. 

• *AVP indicates that multiple occurrences of an AVP are possible. 

5.1.3.2.1 Accounting-Request Message 

Table 5.4 illustrates the basic structure of a Diameter Accounting-Request message as used for offline charging. The use 
of the AVPs is specified in subclause 5.1.3.3 per IMS node and ACR type. 
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Table 5.4: Accounting-Request (ACR) Message Contents for Offline Charging 



Diameter base protocol AVPs 


AVP 


Used in offline ACR 


<Diameter-Header:271 ,REQ,PXY> 


Yes 


<Session-ld> -- Diameter Session Id 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Destination-Realm} 


Yes 


{Accounting-Record-Type} 


Yes 


{Accounting-Record-Number} 


Yes 


[Acct-Application-ld] 


No 


[Vendor-Specific-Application-ld] 


Yes 


[User-Name] 


Yes 


[Accounting-Sub-Session-Id] 


No 


[Accounting-RADIUS-Session-ld] 


No 


[Acct-Multi-Session-ld] 


No 


[Acct-lnterim-lnterval] 


Yes 


[Accounting-Realtime-Required] 


No 


[Origin-State-Id] 


Yes 


[Event-Timestamp] 


Yes 


*[Proxy-lnfo] 


No 


*[Route-Record] 


No 


*[AVP] 


No 


Diameter Credit Control AVP 


[Subscription-Id] 


No 


[Requested-Action] 


No 


*[Requested-Service-Unit] 


No 


*[Used-Service-Unit] 


No 


*[Service-Parameter-lnfo] 


No 


[Abnormal-Termination-Reason] 


No 


*[Accounting-Correlation-ld] 


No 


[Credit-Control-Failure-Handling] 


No 


[Direct-Debiting-Failure-Handling] 


No 


[Re-Transmission] 


Yes 


3GPP Diameter accounting AVPs 


[Event-Type] 


Yes 


[Role-of-node] 


Yes 


[User-Session-ID ] 


Yes 


[Calling-Party-Address] 


Yes 


[Called-Party-Address] 


Yes 


[Time-stamps] 


Yes 


'[Application-Server] 


Only for S-CSCF 


*[Application-provided-Called-Party-Address] 


Only for S-CSCF 


*[lnter-Operator-ldentifier] 


Yes 


[IMS-Charging-ldentifier] 


Yes 


*[SDP-Session-Description] 


Yes 


*[SDP-Media-Component] 


Yes 


[GGSN-Address] 


Yes 


[Served- Party- 1 P-Address] 


Only for S-CSCF 


[Authorised-QoS] 


Only for P-CSCF 


[Server-Capabilities] 


Only for l-CSCF 


[Trunk-Group-ID] 


Only for MGCF 


[Bearer-Service] 


Only for MGCF 


[Service-ID] 


Only for MRFC 


[UUS-Data] 


Yes 



NOTE: For AVP of type "Grouped" only the group AVP is listed in table 5.4. Detailed descriptions of the AVPs 
is provided in clause 7. 
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5.1.3.2.2 



Accounting-Answer Message 



Table 5.5 illustrates the basic structure of a Diameter Accounting-Answer message as used for IMS charging. This 
message is always used by the CCF as specified below, regardless of the IMS node it is received from and the ACR 
record type that is being replied to. 

Table 5.5: Accounting-Answer (ACA) Message Contents for Offline Charging 



Diameter base protocol AVPs 


AVP 


Used in Offline ACA 


<Diameter-Header:271 ,PXY> 


Yes 


<Session-ld> 


Yes 


{Result-Code} 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Accou nting- Record-Type} 


Yes 


{Accounting-Record-Number} 


Yes 


[Acct-Application-ld] 


No 


[Vendor-Specific-Application-ld] 


Yes 


[User-Name] 


Yes 


[Accounting-Sub-Session-Id] 


No 


[Accounting-RADIUS-Session-ld] 


No 


[Acct-Multi-Session-ld] 


No 


[Error-Reporting-Host] 


No 


[Acct-lnterim-lnterval] 


Yes 


[Accounting-Realtime-Required] 


No 


[Origin-State-Id] 


Yes 


[Event-Tlmestamp] 


Yes 


*[Proxy-lnfo] 


No 


*[AVP] 


No 



5.1.3.2.3 Abort-Session-Request 

Table 5.6 illustrates the basic structure of a Diameter Abort-Session-Request message as used for IMS charging 
Table 5.6: Abort Session Request (ASR) Message Contents 



Diameter base protocol AVPs 


AVP 


Used in ASR 


<Diameter-Header:-274,REQ,-PXY> 


Yes 


<Session-ld> ~ Diameter Session Id 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Destination-Realm} 


Yes 


{Destination-Host} 


Yes 


{Auth-Application-ld} 


Yes 


[User-Name] 


Yes 


[Origin-State-Id] 


No 


*[Proxy-lnfo] 


No 


*[Route-Record] 


No 


*[AVP] 


No 
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5.1.3.2.4 



Abort-Session-Answer 



Table 5.7 illustrate the basic structure of a Diametei Abort-Session-Answer message as used for IMS charging. 
Table 5.7: Abort Session Answer (ASA) Message Contents 



Diameter base 


protocol AVPs 


AVP 


Used in ASA 


<Diameter-Header:-274,-PXY> 


Yes 


<Session-ld> 


Yes 


{Result-Code} 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


[User-Name] 


Yes 


[Origin-State-Id] 


No 


[Error-IVIessage] 


Yes 


[Error-Reporting-Host] 


No 


*[Failed-AVP] 


No 


*[Redirected-Host] 


No 


[Redirected-Host-Usage] 


No 


[Redirected-l\/lax-Cache-Time] 


No 


*[Proxy-lnfo] 


No 


*[AVP] 


No 



5.1.3.3 Detailed Message Formats 

Following the base protocol specification, the following "types" of accounting data may be sent: 

• Start session accounting data. 

• Interim session accounting data. 

• Stop session accounting data. 

• Event accounting data. 

ACR types Start, Interim and Stop are used for accounting data related to successful SIP sessions. In contrast. Event 
accounting data is unrelated accounting data, such as a simple registration or interrogation and successful service event 
triggered by an AS. In addition. Event accounting data are also used for unsuccessful SIP session establishment 
attempts. 

The following table specifies per ACR type the accounting data that are sent by each of the IMS network elements: 

S-CSCF. 

P-CSCF. 

I-CSCF. 

MRFC. 

MGCF. 

BGCF. 

AS. 

The ACR types in the table are listed in the following order: S (start)/I (interim)/S (stop)/E (event). Therefore, when all 
ACR types are possible it is marked as SISE. If only some ACR types are allowed for a node, only the appropriate 
letters are used (i.e. SIS or E) as indicated in the table heading. The omission of an ACR type for a particular AVP is 
marked with "-" (i.e. SI-E). Also, when an entire AVP is not allowed in a node the entire cell is marked as "-". 

Note that not for all Grouped AVPs the individual AVP members are listed in the table. See clause 7 for a detailed list 
of the AVP group members and for the description of the AVPs. 
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For the AC A the same details listed in table 5.8 applies with the addition that Error-Reporting-Host AVP is supported 
in all ACAs in a similar manner as most other base protocol AVPs (e.g. in the same manner as Origin-State-Id AVP). 

Table 5.8: Detailed Diameter ACR Message Contents for Offline Charging 



AVP name 


Node Type 


S-CSCF 


P-CSCF 


l-CSCF 


MRFC 


MGCF 


BGCF 


AS 


Supported ACRs 


S/l/S/E 


S/l/S/E 


E 


S/l/S 


S/l/S/E 


S/l/S/E 


S/l/S/E 


AVPs from the Diameter base protocol 


<Session-ld> 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Origin-Host} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Origin-Realm} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Destination-Realm} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Accounting-Record-Type} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Accounting-Record-Number} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Vendor-Specific-Application-ld] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Acct-Application-ld] 


- 


- 


- 


- 


- 


- 


- 


[User-Name] (see note 1) 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Accounting-Sub-Session-Id] 


- 


- 


- 


- 


- 


- 


- 


[Accounting-RADIUS-Session-ld] 


- 


- 


- 


- 


- 


- 


- 


[Acct-Multi-Session-ld] 


- 


- 


- 


- 


- 


- 


- 


[Acct-lnterim-lnterval] 


SIS- 


SIS- 


- 


SIS- 


SIS- 


SIS- 


SIS- 


[Accounting-Realtime-Required] 


- 


- 


- 


- 


- 


- 


- 


[Origin-State-Id] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Event-Tlmestamp] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


*[Proxy-lnfo] 


- 


- 


- 


- 


- 


- 


- 


*[Route-Record] 


- 


- 


- 


- 


- 


- 


- 


*[AVP] 


- 


- 


- 


- 


- 


- 


- 


Diameter Credit Control AVP 


[Subscription-Id] 


- 


- 


- 


- 


- 


- 


- 


[Requested-Action] 


- 


- 


- 


- 


- 


- 


- 


*[Requested-Service-Unit] 


- 


- 


- 


- 


- 


- 


- 


*[Used-Service-Unit] 


- 


- 


- 


- 


- 


- 


- 


*[Service-Parameter-lnfo] 


- 


- 


- 


- 


- 


- 


- 


[Abnormal-Termination-Reason] 


- 


- 


- 


- 


- 


- 


- 


*[Accounting-Correlation-ld] 


- 


- 


- 


- 


- 


- 


- 


[Credit-Control-Failure-Handling] 


- 


- 


- 


- 


- 


- 


- 


[Direct-Debiting-Failure-Handling] 


- 


- 


- 


- 


- 


- 


- 


[Re-Transmission] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


3GPP Diameter accounting AVPs 


[Event-Type] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Role-of-Node] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[User-Session-Id] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Calling-Party-Address] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Called-Party-Address] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Time-stamps] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


*[Application-server] (see note 1 ) 


SISE 


- 


- 


- 


- 


- 


- 


*[Application-Provided-Called-Party- 
Address] (see note 1) 


SISE 


- 


- 


- 


- 


- 


- 


[Inter-Operator-Identifiers] 
(see note 1 ) 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[IMS-Charging-ldentifier] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


*[SDP-Session-Description] 
(see note 2) 


Sl-E 


Sl-E 


- 


Sl- 


Sl-E 


Sl-E 


Sl-E 


*[SDP-Media-component] 
(see note 2) 


Sl-E 


Sl-E 




Sl- 


Sl-E 


Sl-E 


Sl-E 


[GGSN-Address] 


Sl-E 


Sl-E 




Sl- 


Sl-E 


Sl-E 


Sl-E 


[Served-Party-IP-Address] 
(see note 1 ) 


- 


SISE 


- 


- 


- 


- 


- 
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AVP name 


Node Type 


S-CSCF 


P-CSCF 


l-CSCF 


MRFC 


MGCF 


BGCF 


AS 


Supported ACRs 


S/l/S/E 


S/l/S/E 


E 


S/l/S 


S/l/S/E 


S/l/S/E 


S/l/S/E 


[Authorized-QoS] (see note 1 ) 


- 


SISE 


- 


- 


- 


- 


- 


[Server-Capabilities] 


- 


- 


E 


- 


- 


- 


- 


[Trunl<-Group-ID] 


- 


- 


- 


- 


SISE 


- 


- 


[Bearer-Service] 


- 


- 


- 


- 


SISE 


- 


- 


[Service-Id] 


- 


- 


- 


SIS 


- 


- 


- 


[UUS-Data] (see note 3) 


SISE 


SISE 










SISE 


NOTE 1 : Only present if available in the IMS node. 

NOTE 2: Present in Interim and Event ACRs only if the SIP transactions that triggered the ACR contained SDP. 

NOTE 3: Present only if user-to-user data is included in the SIP message that triggered the ACR. 



5.2 CDR Description on the Bi Interface 
5.2.1 CDR Field Types 

The following Standard CDR content and format are considered: 

S-CSCF-CDR generated based on information from the S-CSCF. 

I-CSCF-CDR generated based on information from the I-CSCF. 

P-CSCF-CDR generated based on information from the P-CSCF. 

BGCF-CDR generated based on information from the BGCF. 

MGCF-CDR generated based on information from the MGCF. 

MRFC-CDR generated based on information from the MRFC. 

AS-CDR generated based on information from the AS. 

The content of each CDR type is defined in the tables that are part of this subclause. For each CDR type the field 
definition includes the field name, description and category. 

Equipment vendors shall be able to provide all of the fields listed in the CDR content tables in order to claim 
compliance with the present document. However, since CDR processing and transport consume network resources, 
operators may opt to eliminate some of the fields that are not essential for their operation. This operator provisionable 
reduction is specified by the field category. 

A field category can have one of two primary values: 

M This field is Mandatory and shall always be present in the CDR. 

C This field shall be present in the CDR only when certain Conditions are met. These Conditions are specified as 
part of the field definition. 

Some of these fields are designated as Operator provisionable. Using TMN management functions or specific tools 
provided by an equipment vendor, operators may choose if they wish to include or omit the field from the CDR. Once 
omitted, this field is not generated in a CDR. To avoid any potential ambiguity, a CDR generating element MUST be 
able to provide all these fields. Only an operator can choose whether or not these fields should be generated in their 

system. 

Those fields that the operator may configure to be present or absent are further qualified with the "Operator 
provisionable" subscript as follows: 

Mo This is a field that, if provisioned by the operator to be present, shall always be included in the CDRs. In other 
words, an Mq parameter that is provisioned to be present is a mandatory parameter. 

Co This is a field that, if provisioned by the operator to be present, shall be included in the CDRs when the 
required conditions are met. In other words, a Co parameter that is configured to be present is a conditional 
parameter. 
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The CCF provides the CDRs at the Bi interface in the format and encoding described in the present document. 
Additional CDR formats and contents may be available at the interface to the billing system to meet the requirements of 
the billing system, these are outside of the scope of 3GPP standardisation. 

5.2.2 CDR Triggers 



5.2.2.1 



Session Related CDRs 



Reflecting the usage of multimedia sessions IMS CDRs are generated by the CCF on a per session level. In the scope of 
the present document the term "session" refers always to a SIP session. The coherent media components are reflected 
inside the session CDRs with a media component container comprising of all the information necessary for the 
description of a media component. 

Accounting information for SIP sessions is transferred from the IMS nodes involved in the session to the CCF using 
Diameter ACR Start, Interim and Stop messages. A session CDR is opened in the CCF upon reception of a Diameter 
ACR [Start] message. Session CDRs are updated, or partial CDRs generated, upon reception of a Diameter ACR 
[Interim] message. The CCF closes the final session CDR upon reception of a Diameter ACR [Stop] message, which 
indicates that the SIP session is terminated. Further details on triggers for the generation of IMS CDRs are specified 
in [2]. 

Accounting information for unsuccessful session set-up attempts may be sent by the IMS node to the CCF employing 
the Diameter ACR [Event] message. The behaviour of the CCF upon receiving ACR [Event] messages is specified in 

subclause 5.2.2.2. 



5.2.2.2 



Session Unrelated CDRs 



To reflect chargeable events not directly related to a session the CCF may generate CDRs upon the occurrence of 
session unrelated SIP procedures, such as registration respectively de-registration events. Accounting information for 
SIP session-unrelated procedures is transferred from the IMS nodes involved in the procedure to the CCF using 
Diameter ACR [Event] messages. Session unrelated CDRs are created in the CCF in a "one-off" action based on the 
information contained in the Diameter ACR [Event] message. One session unrelated CDR is created in the CCF for 
each Diameter ACR [Event] message received, whereas the creation of partial CDRs is not applicable for session 
unrelated CDRs. The cases for which the IMS nodes send ACR [Event] messages are listed per SIP procedure in 
tables 5.1 and 5.2. 

Further details on triggers for the generation of IMS CDRs are specified in [2] . 

5.2.3 CDR Content 

5.2.3.1 Charging Data in S-CSCF (S-CSCF-CDR) 

Table 5.9: S-CSCF Charging Data (S-CSCF-CDR) 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record: S-CSCF-CDR. 


Retransmission 


Co 


This parameter, when present, indicates that information from retransmitted 
Diameter ACRs has been used in this CDR. 


Event Type 


Mo 


Reflects the type of chargeable telecommunication service/event for which the 
CDR is generated, such as: "session", "register", "subscribe". 


Role of Node 


Mo 


Specifies the role of the CSCF if relevant for the chargeable telecommunication 
service/event, which is either: 
Originating role (serving A) 
Terminating role (serving B) 


Node Address 


Mo 


The address of the S-CSCF providing the information for the CDR. 


Session ID 


Mo 


The Session identification. For a SIP session the Session ID contains the SIP 
Call ID as defined in the Session Initiation Protocol. 


Calling Party Address 
(Public User ID) 


Mo 


The address of the party initiating a session (SIP URL, E.164 ...) 


Called Party Address 
(Public User ID) 


Mo 


The address of the party to whom a session is established (SIP URL, E.164 ...) 
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Field 


Category 


Description 


Private User ID 
(served party) 


Mo 


Holds the used Network Access Identifier according to RFC2486 [6]. This 
parameter corresponds to the User-Name AVP. 


Record Opening Time 


Mo 


A time stamp reflecting the time the CCF opened this record. 


Record Closure Time 


Mo 


A Time stamp reflecting the time the CCF closed the record. 


List of AS Involved 


Co 


Holds a list of ASs (if any) identified by the SIP URLs 


List of AS Provided 
Called Party 
Addresses 


Co 


Holds a list of the Called Party Address(es), if the address(es) are determined by 
an AS (SIP URL, E.164...). 


Inter Operator 
Identifier(s) 


Co 


Holds the identification of the network neighbours (originating and terminating) if 
exchanged via SIP signalling. 


Local Record 
Sequence Number 


Mo 


Contains a unique record number created by this CCF. 


Partial Record 
Sequence Number 


Co 


The partial record number, if partial records are generated. 


Cause for Record 
Closure 


Mo 


Identifies the reason for CDR closure, such as: 

time limit, service change (e.g. change in media components), network internal 

reasons, end of session, tariff time change. 


IMS Charging Identifier 
(ICID) 


Mo 


Holds the ICID as received from the S-CSCF. 


SDP Session 
Description 


Co 


Holds the Session Description if exchanged between the User Agents. 


List of Session 
Modifications 


Mo 


List of session information exchanged via SIP signalling by the user agent(s) 
and the related timestamps. 




SIP Request 
Timestamp 


Co 


This parameter contains the time of the initial SIP Request (usually a (Re)lnvite), 
as provided by the S-CSCF. Only present if the CDR is opened by the reception 
of an ACR containing the time stamp. 


SIP Response 
Timestamp 


Co 


This parameter contains the time of the response to the initial SIP Request 
(usually a 200 OK), as provided by the S-CSCF. Only present if the CDR is 
opened by the reception of an ACR containing the time stamp. 


SDP Media 
Component 


Co 


Holds the media components if specified in the SDP data. 


Media Initiator 
Flag 


Co 


This is a flag that is present only if the called party requested the session 
modification. 


GPRS 
Charging ID 


Co 


If IMS is accessed via GPRS, the GPRS charging ID generated by the GGSN 
whose address is contained in the parameter "GGSN Address". 


GGSN Address 


Co 


Holds the IP-address of the GGSN that was used for the SIP session, if IMS is 
accessed via GPRS. 


Cause 


Mo 


A more specific reason for the closure of the CDR. The possible values of this 
parameter depend on the "Cause for Record Closure". 


User-to-User Data 


Co 


This parameter describes the user-to-user data, if carried in the SIP signaling. 


Record Extensions 


Co 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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5.2.3.2 



Charging Data in P-CSCF (P-CSCF-CDR) 



Table 5.10: P-CSCF Charging Data (P-CSCF-CDR) 



Field 


Category 


Description 


Record Type 


Mo 


Identifies the type of record: P-CSCF-CDR. 


Event Type 


Mo 


Reflects the type of chargeable telecommunication service/event for which 
the CDR is generated, such as: "session", "register", "subscribe". 


Role of Node 


Mo 


Specifies the role of the CSCF if relevant for the chargeable 
telecommunication service/event, which is either: 
Originating role (serving A) 
Terminating role (serving B) 


Node Address 


Mo 


The address of the node providing the information for the CDR. 


Session ID 


Mo 


The Session identification. For a SIP session the Session ID contains the 
SIP Call ID as defined in the Session Initiating Protocol. 


Calling Party Address 
(Public User ID) 


Mo 


The address of the party initiating a session (SIP URL, E.164 ...) 


Called Party Address 
(Public User ID) 


Mo 


The address of the party to whom a session is established (SIP URL, E.164 
...) 


Served party IP 
Address 


Mo 


Holds the IP address of either the calling or called party, depending on 
whether the proxy is in touch with the calling or the called party 


Record Opening Time 


Mo 


A time stamp reflecting the time the CCF opened this record. 


Record Closure Time 


Mo 


A Time stamp reflecting the time the CCF closed the record. 


Inter Operator 
Identifier(s) 


Co 


Holds the identification of the network neighbours (originating and 
terminating) if exchanged via SIP signalling. 


Local Record 
Sequence Number 


Mo 


Contains a unique record number created by this CCF. 


Partial Record 
Sequence Number 


Co 


The partial record number, if partial records are generated. 


Cause for Record 
Closure 


Mo 


Identifies the reason for CDR closure, such as: time limit, service change 
(e.g. change in media components), network internal reasons, end of 
session, tariff time change. 


IMS Charging Identifier 
(ICID) 


Mo 


Holds the ICID as received from the P-CSCF. 


List of Session 
IVIodifications 


Mo 


List of session information exchanged via SIP signalling by the user agent(s) 
and the related timestamps. 




SIP Request 
Timestamp 


Co 


This parameter contains the time of the initial SIP Request (usually a 
(Re)lnvite), as provided by the P-CSCF. Only present if the CDR is opened 
by the reception of an ACR containing the time stamp. 




SIP Response 
Timestamp 


Co 


This parameter contains the time of the response to the initial SIP Request 
(usually a 200 OK), as provided by the P-CSCF. Only present if the CDR is 
opened by the reception of an ACR containing the time stamp. 


SDP IVIedia 
Component 


Co 


Holds the media components if specified in the SDP data. 


IVIedia Initiator 
Flag 


Co 


This is a flag that is present only if the called party requested the session 
modification. 


Authorised 
OoS 


Co 


Authorised OoS as defined in TS 23.207 7] / TS 29.207 [8] and applied via 
the Go interface 


GPRS 
Charging ID 


Co 


If IMS is accessed via GPRS, the GPRS charging ID generated by the 
GGSN whose address is contained in the parameter "GGSN Address". 


GGSN Address 


Co 


Holds the IP-address of the GGSN that was used for the SIP session, if IMS 
is accessed via GPRS. 


Cause 


Mo 


A more specific reason for the closure of the CDR. The possible values of 
this parameter depend on the "Cause for Record Closure". 


User-to-User Data 


Co 


This parameter will describe the user-to-user data, if carried in the SIP 
signaling. 


Record Extensions 


Co 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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5.2.3.3 



Charging Data in l-CSCF (l-CSCF-CDR) 



Table 5.1 1 : l-CSCF Charging Data (l-CSCF-CDR) 



Field 


Category 


Description 


Record Type 


Mo 


Identifies the type of record: l-CSCF-CDR. 


Event Type 


Mo 


Reflects the type of chargeable telecommunication service/event for which 
the CDR is generated, such as: "session", "register", "subscribe". 


Node Address 


Mo 


The address of the node providing the information for the CDR. 


Session ID 


Mo 


The Session identification. For a SIP session the Session ID contains the 
SIP Call ID as defined in the Session Initiating Protocol. 


Calling Party Address 
(Public User ID) 


Mo 


The address of the party initiating a session (SIP URL, E.164 ...) 


Called Party Address 
(Public User ID) 


Mo 


The address of the party to whom a session is established (SIP URL, E.164 
...) 


Transaction time 
stamp 


Mo 


Time stamp reflecting the time for transaction termination (Upon 
receiving/generating the final response for the SIP request) 


Inter Operator 
Identifier(s) 


Co 


Holds the identification of the network neighbours (originating and 
terminating) if exchanged via SIP signalling. 


Local Record 
Sequence Number 


Mo 


Contains a unique record number created by this node. 


S-CSCF information 


Co 


Information related to the serving CSCF, e.g. the S-CSCF capabilities upon 
registration event or the S-CSCF address upon the session establishment 
event. 


IMS Charging Identifier 
(ICID) 


Mo 


Holds the ICID as received from the MRFC. 


Record Extensions 


Co 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 



£75/ 



3GPP TS 32.225 version 5.1.0 Release 5 



39 



ETSI TS 132 225 V5.1.0 (2002-12) 



5.2.3.4 



Charging Data in IVIRFC (IVIRFC-CDR) 



Table 5.12: MRFC Charging Data (MRFC-CDR) 



Field 


Category 


Description 


Record Type 


Mo 


Identifies the type of record: MRFC-CDR. 


Node Address 


Mo 


The address of the node providing the information for the CDR. 


Session ID 


Mo 


The Session identification. For a SIP session the Session ID contains the 
SIP Call ID as defined in the Session Initiating Protocol. 


Service ID 


Mo 


Identifies the service the MRFC is hosting. For conferences the conference 
ID is used here. 


Calling Party Address 
(Public User ID) 


Mo 


The address of the party initiating a session (SIP URL, E.164 ...) 


Called Party Address 
(Public User ID) 


Mo 


The address of the party to whom a session is established (SIP URL, E.164 
...) 


Record Opening Time 


Mo 


A time stamp reflecting the time the CCF opened this record. 


Record Closure Time 


Mo 


A Time stamp reflecting the time the CCF closed the record. 


Inter Operator 
Identifier(s) 


Co 


Holds the identification of the network neighbours (originating and 
terminating) if exchanged via SIP signalling. 


Local Record 
Sequence Number 


Mo 


Contains a unique record number created by this CCF. 


Partial Record 
Sequence Number 


Co 


The partial record number, if partial records are generated. 


Cause for Record 
Closure 


Mo 


Identifies the reason for CDR closure, such as: time limit, service change 
(e.g. change in media components), network internal reasons, end of 
session, tariff time change. 


IMS Charging Identifier 
(ICID) 


Mo 


Holds the ICID as received from the MRFC. 


List of session 
Modifications 


Mo 


List of session information exchanged via SIP signalling by the user agent(s) 
and the related timestamps. 




SIP Request 
Timestamp 


Co 


This parameter contains the time of the initial SIP Request (usually a 
(Re)lnvite), as provided by the MRFC. Only present if the CDR is opened by 
the reception of an ACR containing the time stamp. 


SIP Response 
Timestamp 


Co 


This parameter contains the time of the response to the initial SIP Request 
(usually a 200 OK), as provided by the MRFC. Only present if the CDR is 
opened by the reception of an ACR containing the time stamp. 


Media Initiator 
Flag 


Co 


This is a flag that is present only if the called party requested the session 
modification. 


GPRS 
Charging ID 


Co 


If IMS is accessed via GPRS, the GPRS charging id generated by the 
GGSN whose address is contained in the parameter "GGSN Address". 


GGSN Address 


Co 


Holds the IP-address of the GGSN that was used for the SIP session, if IMS 
is accessed via GPRS. 


Cause 


Mo 


A more specific reason for the closure of the CDR. The possible values of 
this parameter depend on the "Cause for Record Closure". 


Record Extensions 


Co 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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5.2.3.5 



Charging Data in MGCF (MGCF-CDR) 



Table 5.13: MGCF Charging Data (MGCF-CDR) 



Field 


Category 


Description 


Record Type 


Mo 


Identifies the type of record: MGCF-CDR. 


Role of node 


Mo 


Specifies the role of the CSCF if relevant for the chargeable 
telecommunication service/event, which is either: 
Originating role (serving A) 
Terminating role (serving B) 


Node Address 


Mo 


The address of the node providing the information for the CDR. 


Session ID 


Mo 


The Session identification. For a SIP session the Session ID contains the 
SIP Call ID as defined in the Session Initiating Protocol. 


Calling Party Address 
(Public User ID) 


Mo 


The address of the party initiating a session (SIP URL, E.164 ...) 


Called Party Address 
(Public User ID) 


Mo 


The address of the party to whom a session is established (SIP URL, E.164 
...) 


Record Opening Time 


Mo 


A time stamp reflecting the time the CCF opened this record. 


Record Closure Time 


Mo 


A Time stamp reflecting the time the CCF closed the record. 


Inter Operator 
Identifier(s) 


Co 


Holds the identification of the network neighbours (originating and 
terminating) if exchanged via SIP signalling. 


Local Record 
Sequence Number 


Mo 


Contains a unique record number created by this CCF. 


Partial Record 
Sequence Number 


Co 


The partial record number, if partial records are generated. 


Cause for Record 
Closure 


Mo 


Identifies the reason for CDR closure, such as: time limit, service change 
(e.g. change in media components), network internal reasons, end of 
session, tariff time change. 


IMS Charging Identifier 
(ICID) 


Mo 


Holds the ICID as received from the MGCF. 


List of Session 
IVIodifications 


Mo 


List of session information exchanged via SIP signalling by the user agent(s) 
and the related timestamps. 




SIP Request 
Timestamp 


Mo 


This parameter contains the time of the initial SIP Request (usually a 
(Re)lnvite), as provided by the MGCF. Only present if the CDR is opened by 
the reception of an ACR containing the time stamp. 


SIP Response 
Timestamp 


Mo 


This parameter contains the time of the response to the initial SIP Request 
(usually a 200 OK), as provided by the MGCF. Only present if the CDR is 
opened by the reception of an ACR containing the time stamp. 


List of Session 
IVIodifications 


Mo 


List of session information exchanged via SIP signalling by the user agent(s) 
and the related timestamps. 


Media Initiator 
Flag 


Co 


This is a flag that is present only if the called party requested the session 
modification. 


GPRS 
Charging ID 


Co 


If IMS is accessed via GPRS, the GPRS charging id generated by the 
GGSN whose address is contained in the parameter "GGSN Address". 


GGSN address 


Co 


Holds the IP-address of the GGSN that was used for the SIP session, if IMS 
is accessed via GPRS. 


Cause 


Mo 


A more specific reason for the closure of the CDR. The possible values of 
this parameter depend on the "Cause for Record Closure". 


Trunk Group ID 
Incoming/Outgoing 


Mo 


PSTN leg: 

Contains the outgoing trunk group ID for an outgoing session/call 

Contains the incoming trunk group ID for an incoming session/call 


Bearer Service 


Mo 


Holds the used bearer service for the PSTN leg 


Record Extensions 


Co 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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5.2.3.6 



Charging Data in BGCF (BGCF-CDR) 



Table 5.14: BGCF Charging Data (BGCF-CDR) 



Field 


Category 


Description 


Record Type 


Mo 


Identifies the type of record: BGCF-CDR. 


Node Address 


Mo 


The address of the node providing the information for the CDR 


Session ID 


Mo 


The Session identification. For a SIP session the Session ID contains the 
SIP Call ID as defined in the Session Initiating Protocol. 


Calling Party Address 
(Public User ID) 


Mo 


The address of the party initiating a session (SIP URL, E.164 ...) 


Called Party Address 
(Public User ID) 


Mo 


The address of the party to whom a session is established (SIP URL, E.164 
...) 


Record Opening Time 


Mo 


A time stamp reflecting the time the CCF opened this record. 


Record Closure Time 


Mo 


A Time stamp reflecting the time the CCF closed the record. 


Inter Operator 
Identifier(s) 


Co 


Holds the identification of the network neighbours (originating and 
terminating) if exchanged via SIP signalling. 


Local Record 
Sequence Number 


Mo 


Contains a unique record number created by this CCF. 


Partial Record 
Sequence Number 


Co 


The partial record number, if partial records are generated. 


Cause for Record 
Closure 


Mo 


Identifies the reason for CDR output, such as: 

time limit, service change (e.g. change in media components), network 

internal reasons, last CDR, tariff time change. 


IIVIS Charging Identifier 
(ICID) 


Mo 


Holds the ICID as received from the BGCF. 


List of Session 
Modifications 


Mo 


List of session information exchanged via SIP signalling by the user agent(s) 
and the related timestamps. 




SIP Request 
Timestamp 


Co 


This parameter contains the time of the initial SIP Request (usually a 
(Re)lnvite), as provided by the BGCF. Only present if the CDR is opened by 
the reception of an ACR containing the time stamp. 


SIP Response 
Timestamp 


Co 


This parameter contains the time of the response to the initial SIP Request 
(usually a 200 OK), as provided by the BGCF. Only present if the CDR is 
opened by the reception of an ACR containing the time stamp. 


SDP Media 
Component 


Co 


Holds the media components if specified in the SDP data. 


Media Initiator 
Flag 


Co 


This is a flag that is present only if the called party requested the session 
modification. 


GPRS 
Charging ID 


Co 


If IMS is accessed via GPRS, the GPRS charging id generated by the 
GGSN whose address is contained in the parameter "GGSN Address". 


GGSN address 


Co 


Holds the IP-address of the GGSN that was used for the SIP session, if IMS 
is accessed via GPRS. 


Cause 


Mo 


A more specific reason for the closure of the CDR. The possible values of 
this parameter depend on the "Cause for Record Closure". 


Record Extensions 


Co 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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5.2.3.7 



Charging Data in AS (AS-CDR) 



Table 5.15: AS Charging Data (AS-CDR) 



Field 


Category 


Description 


Record Type 


Mo 


Identifies the type of record: AS-CDR. 


Node Address 


Mo 


The address of the node providing the information for the CDR 


Session ID 


Mo 


The Session identification. For a SIP session the Session ID contains the 
SIP Call ID as defined in the Session Initiating Protocol. 


Calling Party Address 
(Public User ID) 


Mo 


The address of the party initiating a session (SIP URL, E.164 ...) 


Called Party Address 
(Public User ID) 


Mo 


The address of the party to whom a session is established (SIP URL, E.164 
...) 


Record opening time 


Mo 


A time stamp reflecting the time the CCF opened this record. 


Record closure time 


Mo 


A Time stamp reflecting the time the CCF closed the record. 


Inter Operator 
Identifier(s) 


Co 


Holds the identification of the network neighbours (originating and 
terminating) if exchanged via SIP signalling. 


Local Record 
Sequence Number 


Mo 


Contains a unique record number created by this CCF. 


Partial Record 
Sequence Number 


Co 


The partial record number, if partial records are generated. 


Cause for Record 
Closure 


Mo 


Identifies the reason for CDR closure, such as: time limit, service change 
(e.g. change in media components), network internal reasons, end of 
session, tariff time change. 


IIVIS Charging Identifier 
(ICID) 


Mo 


Holds the ICID as received from the MGCF. 


List of Session 
Modifications 


Mo 


List of session information exchanged via SIP signalling by the user agent(s) 
and the related timestamps. 




SIP Request 
Timestamp 


Mo 


This parameter contains the time of the initial SIP Request (usually a 
(Re)lnvite), as provided by theAS. Only present if the CDR is opened by the 
reception of an ACR containing the time stamp. 


SIP Response 
Timestamp 


Mo 


This parameter contains the time of the response to the initial SIP Request 
(usually a 200 OK), as provided by theAS. Only present if the CDR is 
opened by the reception of an ACR containing the time stamp. 


SDP Media 
Component 


Co 


Holds the media components if specified in the SDP data. 


Media Initiator 
Flag 


Co 


This is a flag that is present only if the called party requested the session 
modification. 


GPRS 
Charging ID 


Co 


If IMS is accessed via GPRS, the GPRS charging id generated by the 
GGSN whose address is contained in the parameter "GGSN Address". 


GGSN Address 


Co 


Holds the IP-address of the GGSN that was used for the SIP session, if IMS 
is accessed via GPRS. 


Cause 


Mo 


A more specific reason for the closure of the CDR. The possible values of 
this parameter depend on the "Cause for Record Closure". 


Service Specific Data 


Co 


Contains service specific data if present. 


User-to-User Data 


Co 


This parameter will describe the user-to-user data if carried in the SIP 
signaling. 


Record Extensions 


Co 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 



5.2.4 CDR Parameter Description 

Void. 



5.2.4.1 

Void. 



Authorised QoS 



5.2.4.2 

Void. 



Bearer Service 
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5.2.4.3 Called Party Address (Public User ID) 

Void. 

5.2.4.4 Calling Party Address (Public User ID) 

Void. 

5.2.4.5 Cause 

Void. 

5.2.4.6 Cause for Record Closure 

Void. 

5.2.4.7 Event Type 

Void. 

5.2.4.8 GGSN Address 

This parameter holds the IP address of the GGSN that handles on or more media component(s) of a IMS session. If 
GPRS is used to access the IMS, the GGSN address is used together with the GPRS charging ID as the access part of 
the charging correlation vector. The charging correlation vector is comprised of an access part and an IMS part, which 
is the IMS Charging Identifier. For further information regarding the composition of the charging correlation vector 
refer to the appropriate clause in TS 32.200 [2]. 

5.2.4.9 GPRS Charging ID 

This parameter holds the GPRS charging ID (GCID) as generated by the GGSN for a GPRS PDP context. There is a 1:1 
relationship between the GCID and the PDP context. If GPRS is used to access the IMS, the GCID is used together with 
the GGSN address as the access part of the charging correlation vector that is comprised of an access part and an IMS 
part, which is the IMS Charging Identifier. 

For further information regarding the composition of the charging correlation vector refer to the appropriate clause in 
TS 32.200 [2]. 

5.2.4.10 IMS Charging Identifier (ICID) 

This parameter holds the IMS charging identifier (ICID) as generated by the IMS node for the SIP session. There is a 
1 : 1 relationship between the ICID and the session ID. The ICID is part of the charging correlation vector and coded as 
US-ASCII (as are all SIP messages). The charging correlation vector contains an IMS part (ICID - a unique number 
plus an IP address) and an access part (GPRS Charging ID and GGSN address). For further information regarding the 
composition and usage of the charging correlation vector refer to TS 32.200 [2] and TS 24.229 [14]. 

The ICID is composed of a 4 octet unique number and the IP address of the network node generating the ICID. This is 
inserted in the CDRs as shown in figures 5.13 and 5.14 below. Since IPv4 and IPv6 addresses are supported 
simultaneously, an ICID may either be composed of an IPv4 or IPv6 compliant source address. 
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Octets 
1 
2 
3 
4 
5 
6 

20 


Bits 

8 7 6 5 4 3 2 


1 


Unique value (1" Octet) 


Unique value (2"" Octet) 


Unique value (3'" Octet) 


Unique value (4* Octet) 


IPv6 address (1" Octet) 


IPv6 address (2"" Octet) 




IPv6 address (16* Octet) 



Figure 5.13: ICID layout with IPv6 



Octets 
1 
2 
3 
4 
5 
6 
7 
8 


Bits 

8 7 6 5 4 3 2 


1 


Unique value (1^' octet) 


Unique value (2"*^ octet) 


Unique value (3''^ octet) 


Unique value (4* octet) 


IPv4 address (1" Octet) 


IPv4 address (2"" Octet) 


IPv4 address (3'" Octet) 


IPv4 address (4* octet) 



Figure 5.14: ICID layout with IPv4 

The Unique Value consists of a 32-bit integer, coded as an unsigned integer. Bit 8 of the lowest numbered octet (5 for 
IPv4/17 for IPv6) is the most significant bit and bit 1 of the highest numbered octet (8 for IPv4/20 for IPv6) is the least 
significant bit. 

The IP-address is encoded using binary coding, where each octet in ICID represents one octet in the IP-address. Bit 8 of 
octet 1 is the most significant bit and bit 1 of the highest numbered octet (4 for IPv4/16 for IPv6) is the least significant 
bit. 

The following example, shown in figure 5.15, describes the content of ICID when the unique value of 15409 (H'3C31) 
was generated by a node with the IPv6-address of 255.5.0.0.0.0.0.0.0.0.0.0.0.0.0.179 (FF05::B3): 
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Bits 










Octets 
1 


8 


7 


6 


5 4 


3 


2 


1 


Meaning 
H'3C 








1 


1 1 


1 








2 








1 


1 








1 


H'31 


3 


1 


1 


1 


1 1 


1 


1 


1 


255 


4 














1 





1 


5 


5-17 


























18 


1 





1 


1 





1 


1 


179 


19 


























20 



























Figure 5.15: ICID layout with IPv6 



5.2.4.11 
Void. 



Inter Operator Identifier(s) 



5.2.4.12 

Void. 

5.2.4.13 

Void. 



List of AS Involved 



List of AS Provided Called Party Address 



5.2.4.14 



List of Session Modifications 



List of session information exchanged via SIP signalling by the user agent(s) and the related timestamps. Each entry in 
the list is comprised of the SIP request and response timestamps and media component information as provided in the 
ACR received from the IMS node. New entries are added to the list each time an ACR that includes the SIP request and 
response timestamps is received. 

This implies that the list is not updated when receiving ACRs that are generated by the IMS node due to expiration of 
the Acct-Interim-Interval timer. 

Charging data for media components associated with a session are handled inside the Session CDRs as follows: 

A new media component container is added into a session CDR each time a media component is added to a session. A 
media component container is closed once the related media component is removed from a session. Figure 5.16 
illustrates this principle. 
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Example for a CSCF session CDR 



Session CDR 

Session time stamps 

Calling/called party 

■[.II.IJ.liJ.IJJJ.^M.1 

List of media 
components: 



Media component 1 

SDPdata 

QoS requested/granted 

Time sta m p s sta rt/ sto p 



Correlation vectoraccesspar 



i^ledia component 1 

SDPdata 

QoS requested/granted 

Ti me sta m p s sta rt/ sto p 



CorTBlation vectoraccessnarti 



Cause forsession end 



r 



Cliaiging conelation vector 

ICIDforthe session 
Correlation vectoraccess 
parti, forGPRS this is the 
GGSN address + charging ID 
Correlation vectoraccess 
part 2, forGPRS this is the 
GGSN address + charging ID 



Figure 5.16: Charging Data Record Structure 

A media component container is added into the session CDR when the associated SIP 200 OK message (the one 
corresponding to the appropriate SIP INVITE message) is received in the node generating the CDR. An appropriate 
media component start time stamp reflects the start of this media component. A media component is supposed to be 
removed from a session once either the SIP BYE message or a SIP 200 OK message (corresponding to the SIP INVITE 
message removing a media) is received in the node generating the ACR. The removal of a media component (either due 
to session release or due to a SIP INVITE/200 OK message pair during a session) is reflected with an appropriate time 
stamp inside the media components. If a media component is removed from an ongoing session, the related media 
component container is not carried forward to subsequent partial CDRs (if any). 



5.2.4.15 

Void. 



Local Record Sequence Number 



5.2.4.16 Media Initiator Flag 

This field indicates if the called party has requested the session modification and it is present only if the initiator was the 
called party. 

5.2.4.17 Node Address 

Void. 

5.2.4.18 Partial Record Sequence Number 

Void. 

5.2.4.19 Private User ID (served party) 

This field identifies the served party's private User ID that is received in the User-Name AVP in the Accounting 
Request message. The served party could be either the calling or called party. 
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5.2.4.20 Record Closure Time 

Void. 

5.2.4.21 Record Extensions 

Void. 

5.2.4.22 Record Opening Time 

Void. 

5.2.4.23 Record Type 

Void. 

5.2.4.24 Retransmission 

Void. 

5.2.4.25 Role of Node 

Void. 

5.2.4.26 SDP Media Component 

Void. 

5.2.4.27 SDP Session Description 

Void. 

5.2.4.28 Service ID 

This field identifies the service the MRFC is hosting. For conferences the conference ID is used here. 

5.2.4.29 Service Specific Data 

Void. 

5.2.4.30 Session ID 

Void. 

5.2.4.31 Served party IP Address 

Void. 

5.2.4.32 SIP Request Timestamp 

Void. 

5.2.4.33 SIP Response Timestamp 

Void. 
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5.2.4.34 S-CSCF Information 

This field contains Information related to the serving CSCF, e.g. the S-CSCF capabilities upon registration event or the 
S-CSCF address upon the session establishment event. 

5.2.4.35 Trunk Group ID Incoming/Outgoing 

Void. 

5.2.4.36 User-to-User Data 

Void. 

5.2.5 Bi interface Conventions 

The present document gives several recommendations for the main protocol layers for the Bi interface protocol stack. 
These recommendations are not strictly specified features, since there are a lot of variations among the existing Billing 
Systems. 

As a minimum, all implementations shall support a file based bulk interface for the transfer of CDRs from the CCF to 
the BS. The recommendation is FTP over TCP/IP. 

5.2.6 Abstract Syntax Description 

Void. 

5.2.7 Data Encoding Rules 

Data encoding rules are descried in [9] for BER, in [10] for PER, or in [11] for XER. 

6 Online Charging 

6.1 Diameter Description on the Ro Interface 
6.1.1 Basic Principles 

IMS online charging essentially uses the same protocol that is used for offline charging. However, for online charging 
the protocol may include additional Attribute- Value Pairs (AVPs) within the existing messages. 

Two cases for online event charging are distinguished: 

• Immediate Event Charging (lEC); and 

• Event Charging with Unit Reservation (ECUR). 

In the case of Immediate Event Charging (lEC), granting units to the AS is performed in a single operation that also 
includes the deduction of the corresponding monetary units from the subscriber's account. The charging process is 
controlled by the corresponding Accounting-Record-Type EVENT_RECORD which is sent with an ACR for a given 
accounting event. 

In contrast. Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving, releasing 
and returning unused units. The deduction of the corresponding monetary units then occurs upon conclusion of the 
ECUR transaction. In this case, the Accounting-Record-Type START / INTERIM / STOP_RECORD are used to control 
the accounting session. During a SIP session there can be repeated execution of unit reservation and debit operations as 
specified in TS 32.200 [2]. 
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The AS/MRFC may apply either lEC, where ACR Event messages are generated, or ECUR, using ACR Start, Stop and 
Interim. The decision whether to apply lEC or ECUR is based on the service and/or operator's policy. 

NOTE: To the extent possible alignment with the IETF Credit Control Application, [13], is planned. However, 
this can only be accomplished when the current IETF draft receives an official RFC status. 

6.1 .2 Message Flows and Types 

This subclause describes the message flows for the event charging procedures on the Ro interface. 

6.1 .2.1 Immediate Event Charging (lEC) 

This subclause provides the details of the "Debit Units" operation specified in TS 32.200 [2]. 

6.1 .2.1 .1 Message Flows - Successful Cases and Scenarios 



6.1.2.1.1.1 



lEC - Debit Units Operation 



Figure 6. 1 shows the transactions that are required on the Ro interface in order to perform lEC with Debit Units 
operations. The Debit Units operation may alternatively be carried out prior to, concurrently with or after 
service/content delivery. The AS/MRFC must ensure that the requested service execution is successful, when this 
scenario is used. 



AS / MRFC 



1 . Service Request 



5. Service Delivery 



ECF 



Debit Units Operation 



2. ACR (EVENT^RECC'RD, Debit Units Req.) 



3. Perform Event 
Qiarging Control 



4. ACA (EVENT_RECORD, Debit Units Res.) 



Figure 6.1 : lEC - Debit Units Operation 

1. The AS/MRFC receives a SIP related service request from S-CSCF. 

The Debit Units Operation is performed as described in TS 32.200 [2]. 



2. 



The AS/MRFC performs lEC prior to service execution. AS/MRFC sends Accounting-Request 
with Accounting-Record-Type set to EVENT_RECORD to indicate service specific information to 
the ECF. The Requested-Action is set to DIRECT_DEBITING. If known, the AS/MRFC may 
include Requested-Service-Unit (monetary or non monetary units) in the request message. 
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3. If the service cost information is not received by the ECF, the ECF determines the price of the 
service according to the service specific information received by issuing a rating request to the 
Rating Function. The ECF then deducts the corresponding monetary amount. If the cost of the 
service is included in the request received from the AS/MRFC, the ECF directly deducts the 
specified monetary amount from the user's account. 

4. The ECF returns Accounting-Answer message with Accounting-Record-Type set to 
EVENT_RECORD to the AS/MRFC in order to authorize the service execution 
{Granted-Service-Unit and possibly Cost-Information indicating the cost of the service are 
included in the Accounting-Answer message). The Accounting- Answer message has to be checked 
by the AS/MRFC accordingly and the requested service is controlled concurrently with service 
delivery. 

5. Service is being delivered. 

6.1 .2.1 .2 Message Flows - Error Cases and Scenarios 

This subclause describes various error cases and how these should be handled. 

The failure handling behavior is locally configurable in the AS/MRFC. If the Direct-Debiting-Failure-Handling AVP is 
not used, the locally configured values are used instead. 

6.1 .2.1 .2.1 Reception of SIP Error Messages 

If SIP errors occur during service delivery, as defined in [5] and [12], it is up to the AS/MRFC to determine to what 
extent the service was delivered before the error occurred and act appropriately with respect to charging. This may 
imply that no units at all (or no more units) are debited. 

6.1 .2.1 .2.2 Debit Unit Operation Failure 

This case comprises of ECF connection failure and/or receiving error responses from the ECF. 

The AS/MRFC detects an ECF connection failure when the timer Tx expires [13] or a transport failure is detected as 
defined in [3]. The ECF should indicate the cause of failure by setting the appropriate result code as defined in [3] and 
[13]. In any case, the failure handling of AS/MRFC and ECF complies with the failure procedures for "Direct Debiting" 
scenario described in "draft-hakala-diameter-credit-control-03", [13]. 

6.1.2.1.2.3 Duplicate Detection 

The detection of duplicate request is needed and must be enabled. To speed up and simplify as much as possible the 
duplicate detection, the all-against-all record checking should be avoided and just those records marked as potential 
duplicates need to be checked against other received requests (within a reasonable time window) by the receiver entity. 

The AS/MRFC mark the request messages that are retransmitted after a link failover as possible duplicates with the 
Re-Transmission AVP. For optimized performance, uniqueness checking against other received requests is only 
necessary for those records marked with the Re-Transmission AVP received within a reasonable time window. This 
focused check is based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. 

Note that for lEC the duplicate detection is performed in the Correlation Function that is part of the OCS. The ECF that 
receives the possible duplicate request should mark as possible duplicate the corresponding request that is sent over the 
Re interface. 

6.1 .2.2 Event Charging with Unit Reservation (ECUR) 

This subclause provides the details of the "Reserve Units" and "Debit Units" operations specified in TS 32.200 [2]. 

6.1 .2.2.1 Message Flows - Successful Cases and Scenarios 

6.1 .2.2.1 .1 ECUR - Reserve Units and Debit Units Operations 

Figure 6.2 shows the transactions that are required on the Ro interface in order to perform ECUR with Reserve Units 
and Debit Units operations. Multiple replications of both of these operations are possible. 
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1 . Service Request 



5. Service Delivery 



9. Service Delivery 



Reserve Units Operation 



2. ACR (START_RECORE , Reserve Units Req.) 



3. Perform Event 
Ciiarging Control 



4. ACA (START_RECORD, Reserve Units Res.) 



Reserve Units and Debit Units Operations 



:R (INTERIM_REC0RD, Deb 



t units+Reserve units Req.) 



7. Perform Event Charging Control 



:A (fNTERfM_RECORD, Deb t units+Reserve units Req.) 



Debit Units Operation 



10. ACR (STOP_RECORD, I ebit Units Req.) 



11. Perform Event Charging Conu-ol 



12. ACA (STOP_RECORD, I )ebit Units Res.) 



Figure 6.2: ECUR - Reserve Units and Debit Units Operations 



1. The AS/MRFC receives a SIP related service request from S-CSCF. The service request may be 

initiated by either the user or an AS/MRFC. 

The Reserve Units Operation is performed as described in TS 32.200 [2]. 



2. 



3. 



5. 



In order to perform Reserve Units operation for a number of units (monetary or non-monetary 

units), the AS/MRFC sends an ACR with Accounting-Record-Type set to START_RECORD to 

the ECF. If known, the AS/MRFC may include Requested-Service-Unit (monetary or non 

monetary units) in the request message. 

If the service cost information is not received by the ECF, the ECF determines the price of the 

desired service according to the service specific information received by issuing a rating request to 

the Rating Function. If the cost of the service is included in the request, the ECF directly reserves 

the specified monetary amount. If the credit balance is sufficient, the ECF reserves the 

corresponding amount from the users account. 

Once the reservation has been made, the ECF returns Accounting-Answer message with 

Accounting-Record-Type set to START_RECORD to the AS/MRFC in order to authorize the 

service execution (Granted-Service-Unit and possibly Cost-Information indicating the cost of the 

service are included in the Accounting-Answer message). 

Content/service delivery starts and the reserved units are concurrently controlled. 
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The Reserve Units and Debit Units Operations are performed as described in TS 32.200 [2]. 

6. During content/service delivery, in order to perform Debit Units and subsequent Reserve Units 
operations, the AS/MRFC sends an ACR with Accounting-Record-Type set to 
INTERIM_RECORD, to report the units used and request additional units, respectively. If known, 
the AS/MRFC may include Requested-Service-Unit (monetary or non monetary units) in the 
request message. 

7. The ECF deducts the amount used from the account. If the service cost information is not received 
by the ECF, the ECF determines the price of the desired service according to the service specific 
information received by issuing a rating request to the Rating Function. If the cost of the service is 
included in the request, the ECF directly reserves the specified monetary amount. If the credit 
balance is sufficient, the ECF reserves the corresponding amount from the users account. 

8. Once the deduction and reservation have been made, the ECF returns Accounting- Answer message 
with Accounting-Record-Type set to INTERIM_RECORD to the AS/MRFC, in order to allow the 
content/service delivery to continue (new Granted-Service-Unit and possibly Cost-Information 
indicating the cumulative cost of the service are included in tht Accounting-Answer message). The 
ECF may include in the AC A the Final-Unit-Indication to indicate the final granted units. 

9. Content/service delivery continues and the reserved units are concurrently controlled. 

The Debit Units Operation is performed as described in TS 32.200 [2]. 

10. When content/service delivery is completed or the final granted units have been consumed, the 
AS/MRFC sends AC/? with Accounting-Record-Type set to STOP_RECORD to terminate the 
active accounting session and report the used units. 

1 1 . The ECF deducts the amount used from the account. Unused reserved units are released, if 
applicable. 

12. The ECF acknowledges the reception of the ACR message by sending ACA message with 
Accounting-Record-Type indicating STOP_RECORD (possibly Cost-Information indicating the 
cumulative cost of the service is included in the Accounting-Answer message). 

6.1 .2.2.1 .2 Support of Tariff Switch 

Changes to the tariffs pertaining to the service may be handled in the following ways. 

• Tariff Changes handled using Acct-Interim-Interval AVP; or 

• Tariff changes handled using the Tariff Switch Time AVP. 

6.1 .2.2.1 .2.1 Tariff CInanges Inandled using Acct-Interim-Interval AVP 

The tariff change for online charging can be achieved by setting the value of the Acct-Interim-Interval AVP (ECF 
controlled) in a manner that it matches the desired tariff switch time. 

6.1 .2.2.1 .2.2 Tariff changes handled using the Tariff Switch Time AVP 

To indicate a change of tariff to the AS/MRFC, the ECF can include the Tariff Switch Time {Tariff-Switch-Definition 
AVP), i.e. a timer value referring to the change of tariff, in the Accounting-Answer. The Tariff Switch Time is evaluated 
by the AS/MRFC relative to the time stamp of the Accounting-Request {Accounting-Record-Type START_RECORD or 
INTERIM_RECORD). By that it is possible to eliminate any delays of the signalhng between AS/MRFC and ECF. 

Together with the Tariff Switch Time the ECF also provides the granted service units. These units can be provided in 
one portion or in two, referring to the granted service units before and after the tariff switch. 

If a Tariff Switch Time is received, the AS/MRFC starts the tariff switch timer and use the granted service units for 
usage metering. If both, granted service units before and after the tariff switch have been provided, the AS/MRFC uses 
the units granted before the tariff switch (pre-switch quota). 

If the pre-switch quota is exhausted, the AS/MRFC sends an Accounting-Request to the ECF. The Accounting-Request 
contains the amount of service units used from the beginning of the connection only. The value of the tariff switch timer 
is discarded in the AS/MRFC and it is the responsibility of the ECF to provide a new Tariff Switch Time in the 
Accounting-Answer. 
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If the tariff switch timer expired, the AS/MRFC further continues usage metering using the post-switch quota, if 
provided, but no Accounting-Request is sent. If no specific units were granted to after tariff switch time, the AS/MRFC 
continues usage metering with the remaining units granted. 

If the post switch quota is exhausted, the AS/MRFC sends an Accounting-Request to the ECF, containing the service 
units used before the last tariff switch, the service units used after the last tariff switch and the tariff switch time. 

If the granted units - provided in one portion - are exhausted, an Accounting-Request is sent. If a tariff switch has 
occurred in this time, the Accounting-Request contains the service units used before the tariff switch, the service units 
used after the tariff switch and the time of the tariff switch. Otherwise, if no tariff switch has occurred, the 
Accounting-Request contains the overall amount of used service units. 

There may be some AS/MRFCs that do no support tariff switching. In this case, the AS/MRFC ignores the AVPs 
associated with this feature (i.e. Tariff-Switch-Definition and Unit-Value-After-Tariff-Switch AVPs). The 
Granted-Service-Unit, Unit-Value and Used-Service-Unit AVPs are treated as if the Tariff Switch feature does not exist. 

Figure 6.3 shows the messages exchanged on the Ro interface for ECUR for a tariff change. This scenario covers a 
tariff switch where the granted service units are provided in two portions, before and after the tariff switch. No 
additional Accounting-Request takes place, as the granted service units were not exhausted. 
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Figure 6.3: Tariff Change in the AS/I\/IRFC 
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1 . In order to perform credit control with reservation of an amount of units (monetary or 
non-monetary units) the AS/MRFC sends an ACR with Accounting-Record-Type set to 
START_RECORD to ECF. The Requested-Action is set to RESERVE_UNITS. 

2. Once the reservation has been made, ECF returns an AC A with Accounting-Record-Type set to 
START_RECORD to the AS/MRFC in order to authorize the content/service dehvery. The ACA 
includes the Tariff Switch Time, the service units granted before the tariff switch and the service 
units granted after the tariff switch. 

Upon receipt of the ACA, the AS/MRFC evaluates the tariff switch time relative to the timestamp 
of the ACR, starts the tariff switch timer and monitors service usage based on the service units 
granted before the tariff switch. 

3. The Tariff Switch Timer expires. The AS/MRFC now monitors service usage based on the service 
units granted after the tariff switch. 

4. The AS/MRFC sends ACR with Accounting-Record-Type set to STOP_RECORD to terminate the 
active accounting session. The message includes the amount of service units used before the tariff 
switch, the amount of service units used after the tariff switch and the time of the tariff change. 

5. An Accounting-Answer is sent from the ECF back to the AS/MRFC as an acknowledgment of the 
successful debit process and to finalize the transaction. 

6.1 .2.2.1 .3 Expiration of Reservation Validity 

This subclause defines how reserved units are returned, if not used, within a reasonable time. It should be possible that 
both the reservation and SIP sessions are cancelled or only the reservation is cancelled without removing the SIP 
session. Work on this is ongoing in IETF Credit Control Draft [13]. AUgnment with [13] is planned. 

6.1 .2.2.2 Message Flows - Error Cases and Scenarios 

This subclause describes various error cases and how these should be handled. 

The failure handling behavior is locally configurable in the AS/MRFC. If Credit-Control-Failure-Handling AVP is not 
used, the locally configured values are used instead. 

6.1 .2.2.2.1 Reception of SIP Error Messages 

If SIP errors occur during service delivery, as defined in [5] and [12], it is up to the AS/MRFC to determine to what 
extent the service was delivered before the error occurred and act appropriately with respect to charging. This may 
imply that no units at all (or no more units) are reserved or debited. 

6.1 .2.2.2.2 Reserve Units and Debit Units Operation Failure 

This case comprises of ECF connection failure, and/or receiving error responses from the ECF. 

The AS/MRFC detects an ECF connection failure when the timer Tx expires [13] or a transport failure is detected as 
defined in [3]. The ECF also has the capability to detect failures when the timer Ts [3] expires. The ECF should indicate 
the cause of failure by setting the appropriate result code as defined in [3] and [13]. In any case, the failure handling of 
AS/MRFC and ECF complies with the failure procedures for "Session Based Credit Control" scenario described in 
" draft-hakala-diameter-credit-control-03 " , [13]. 

6.1.2.2.2.3 Duplicate Detection 

For credit control duplicate detection is performed only for possible duplicate event requests related to lEC as 
mentioned in subclause 6.1.2.1 .2. 3, as retransmission of ECUR related accounting requests is not allowed. 
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6.1.3 Message Formats 

6.1 .3.1 Summary of Online Charging Message Formats 

The existing Diameter credit control extension internet-draft [13] proposes an approach based on a series of 
"interrogations"; 

• Initial interrogation (extending the start-session accounting report message). 

• Zero, one or more interim interrogations (extending the interim accounting report message). 

• Final interrogation (extending the stop-session accounting report message). 

In addition to a series of interrogations, also a one time event (interrogation) can be used e.g. in the case when service 
execution is always successful. 

All of these interrogations make use of the same Accounting-Request and Accounting-Answer messages in the base 
Diameter protocol as for the offline charging. Additional AVPs are specified for the purposes of online charging. These 
additional AVPs include all the AVPs listed in [13] and the Tariff-Switch-Definition AVP as specified in clause 7. 

The Accounting-Request for the "interim interrogation" and "final interrogation" reports the actual number of "units" 
that were used, from what was previously reserved. This determines the actual amount debited from the subscriber's 
account. 

Such an approach has the benefit of a common basic message structure, and accounting data reporting mechanism for 
both offline and online charging. 

Table 6.1 describes the use of these messages for online charging. 

Table 6.1 : Online Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Abbreviation 


Accounting-Request 


MRFC, AS 


ECF 


ACR 


Accounting-Answer 


ECF 


IVIRFC, AS 


ACA 



6.1 .3.2 Structure for the Accounting IVIessage Formats 

The following is the basic structure shared by all online charging messages. This is based directly on the format of the 
Accounting-Request and Accounting-Answer messages defined in the base Diameter protocol specification [3] with the 
extensions defined in [13]. 

Those Diameter AVPs that are used for offline charging are marked "Yes" in tables 6.2 to 6.3. Those Diameter AVPs 
that are not used for online charging are marked "No" in tables 6.2 to 6.3. This implies that their content can (Yes) or 
can not (No) be used by the ECF for charging purposes. 

The following symbols are used in the tables: 

• <AVP> indicates a mandatory AVP with a fixed position in the message. 

• {AVP} indicates a mandatory AVP in the message. 

• [AVP] indicates an optional AVP in the message. 

• *AVP indicates that multiple occurrences of an AVP is possible. 
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6.1.3.2.1 Accounting-Request Message 

Table 6.2 illustrates the basic structure of a Diameter Accounting-Request message as used for IMS online charging 
Table 6.2: Accounting-Request (ACR) Message Contents for Online Charging 



Diameter Base Protocol AVPs 


AVP 


Used in Online ACR 


<Diameter Header: 271, REQ, PXY> 


Yes 


<Session-ld> 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Destination-Realm } 


Yes 


{Accounting-Record-Type} 


Yes 


{Accounting-Record-Number} 


Yes 


[Acct-Application-ld] 


No 


[Vendor-Specific-Application-ld] 


Yes 


[User-Name] 


Yes 


[Accounting-Sub-Session-Id] 


No 


[Accounting-RADIUS-Session-ld] 


No 


[Acct-Multi-Session-ld] 


No 


[Acct-lnterim-lnterval] 


Yes 


[Accounting-Realtime-Required] 


No 


[Origin-State-Id] 


Yes 


[Event-Timestamp] 


Yes 


* [Proxy-Info] 


No 


* [Route-Record] 


No 


*[AVP] 


No 


Diameter Credit Control AVPs 


[Subscription-Id] 


Yes 


[Requested-Action] 


Yes 


*[Requested-Service-Unit] 


Yes 


*[Used-Service-Unit] 


Yes 


[Tariff-Switch-Definition] 


Yes 


*[Service-Parameter-lnfo] 


Yes 


[Abnormal-Termination-Reason] 


Yes 


*[Accounting-Correlation-ld] 


No 


[Credit-Control-Failure-Handling] 


Yes 


[Direct-Debiting-Failure-Handling] 


Yes 


[Re-Transmission] 


Yes 


3GPP Diameter accounting AVPs 


[Event-Type] 


Yes 


[Role-of-node] 


Yes 


[User-Session-ID] 


Yes 


[Calling-Party-Address] 


Yes 


[Called-Party-Address] 


Yes 


[Time-stamps] 


Yes 


*[Application-Server] 


No 


*[Application-Provided-Called-Party-Address] 


No 


*[lnter-Operator-ldentifier] 


Yes 


[IMS-Charging-ldentifier] 


Yes 


*[SDP-Session-Description] 


Yes 


*[SDP-IVIedia-Component] 


Yes 


[GGSN-Address] 


Yes 


[Served-Party-IP-Address] 


No 


[Authorised QoS] 


No 


[Server-Capabilities] 


No 


[Trunk-Group-ID] 


No 


[Bearer-Service] 


No 


[UUS-Data] 


Yes 



The detailed use of the AVPs for MRFC/AS and for each ACR record type (start/interim/stop/event) is specified in 
subclause 6.1.3.3. 
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6.1.3.2.2 



Accounting-Answer Message 



Table 6.3 illustrates the basic structure of a Diameter Accounting-Answer message as used for IMS charging. This 
message is always used by the ECF as specified below, independent of the receiving IMS node and the ACR record 
type that is being replied to. 

Table 6.3: Accounting Answer (ACA) Message Contents for Online Charging 



Diameter base 


protocol AVPs 


AVP 


Used in online ACA 


<Diameter Header: 271, PXY> 


Yes 


<Session-ld> 


Yes 


{Result-Code} 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Accou nting- Record-Type} 


Yes 


{Accounting-Record-Number} 


Yes 


[Acct-Application-ld] 


No 


[Vendor-Specific-Application-Id] 


Yes 


[User-Name] 


Yes 


[Accounting-Sub-Session-Id] 


Yes 


[Accounting-RADIUS-Session-ld] 


No 


[Acct-Multi-Session-ld] 


No 


[Error-Reporting-Host] 


No 


[Acct-lnterim-lnterval] 


Yes 


[Accounting-Realtime-Required] 


No 


[Origin-State-Id] 


Yes 


[Event-Timestamp] 


Yes 


* [Proxy-Info] 


No 


*[AVP] 


No 


Diameter Credit Control AVPs 


[Subscription-Id] 


Yes 


*[Granted-Service-Unit] 


Yes 


[Tariff-Switch-Definition] 


Yes 


[Cost-Information] 


Yes 


[Final-Unit-lndication] 


Yes 


[Check-Balance-Result] 


Yes 


[Credit-Control-Failure-Handling] 


Yes 



6.1.3.3 Detailed Message Formats 

Following the protocol specifications, the following "types" of accounting data may be sent: 

• Start session accounting data. 

• Interim session accounting data. 

• Stop session accounting data. 

• Event accounting data. 

ACR types start, interim and stop are used for accounting data related to successful SIP sessions. In contrast, event 
accounting data is used for session-unrelated accounting data, such as a simple registration or interrogation, and for 
accounting data related to unsuccessful SIP session establishment attempts. 

The following table specifies per ACR type the accounting data that are sent by MRFC and AS. 

Tables 6.4 and 6.5 are the basic structure for online charging messages via Ro Interface. This is based directly on the 
Accounting-Request and Accounting-Answer messages defined in the Diameter protocol specifications [3] and [13]. 



£75/ 



3GPP TS 32.225 version 5.1.0 Release 5 



58 



ETSI TS 132 225 V5.1.0 (2002-12) 



Table 6.4: Detailed Diameter ACR IVIessage Contents for online Charging 



AVP name 


Node Type 


MGCP 


AS 


Supported 
ACRs 


S/l/S/E 


S/l/S/E 


AVPs from Diameter Base Protocol 


<Session-ID> 


SISE 


SISE 


{Origin-Host} 


SISE 


SISE 


{Origin-Realm} 


SISE 


SISE 


{Destination-Realm} 


SISE 


SISE 


{Accounting-Record-Type} 


SISE 


SISE 


{Accounting-Record-Number} 


SISE 


SISE 


[Acct-Application-ID] 


- 


- 


[Vendor-Specific-Application-ID] 


SISE 


SISE 


[User-Name] 


SISE 


SISE 


[Accounting-Sub-Session-ID] 


- 


- 


[Accounting-RADIUS-Session-ID] 


- 


- 


[Acct-Multi-Session-ID] 


- 


- 


[Acct-lnterim-lnterval] 


SIS- 


SIS- 


[Accounting-Realtime-Required] 


- 


- 


[Origin-State-ID] 


SISE 


SISE 


[Event-Timestamp] 


SISE 


SISE 


*[Proxy-lnfo] 


- 


- 


*[Route-Record] 


- 


- 


*[AVP] 


- 


- 


Diameter Credit-Control AVP 


[Subscription-Id] 


SISE 


SISE 


[Requested-Action] 


SISE 


SISE 


*[Requested-Service-Unit] 


SISE 


SISE 


*[Used-Service-Unit] 


SISE 


SISE 


[Tariff-Switch-Definition] 


SISE 


SISE 


•[Service- Parameter- 1 nfo] 


SISE 


SISE 


[Abnormal-Termination-Reason] 


SISE 


SISE 


*[Accounting-Correlation-ld] 


SISE 


SISE 


[Credit-Control-Failure-Handling] 


SISE 


SISE 


[Direct-Debiting-Failure-Handling] 


SISE 


SISE 


*[Granted-Service-Unit] 


- 


- 


[Cost-Information] 


- 


- 


[Final-Unit-lndication] 


- 


- 


[Check-Balance-Result] 


- 


- 


[Re-Transmission] 


SISE 


SISE 


3GPP Diameter Accountinc 


3 AVPs 


[Event-Type] 


SISE 


SISE 


[Role-of-Node] 


SISE 


SISE 


[User-Session-ID] 


SISE 


SISE 


[Calling-Party-Address] 


SISE 


SISE 


[Called-Party-Address] 


SISE 


SISE 


[Time-stamps] 


SISE 


SISE 


[Application-server] 


- 


- 


[Application-provided-called-party-address] 


- 


- 


[1 nter-Operator- Identifiers] 


SISE 


SISE 


[IMS-Charging-ldentifier] 


SISE 


SISE 


*[SDP-Session-Description] 


Sl-E 


Sl-E 


*[SDP-Media-component] 


Sl-E 


Sl-E 


[SDP-Media-Name] 


Sl-E 


Sl-E 


[GGSN-Addressl 


Sl-E 


Sl-E 


GPRS-Charging-ld] 


Sl-E 


Sl-E 


[Served-Party-IP-Address] 


- 


- 


[Authorized-QoS] 


- 


- 


[Server-Capabilities] 


- 


- 


[Trunk-Group-ID] 


- 


- 


[Bearer-Service] 


- 


- 


[Service-Id] 


- 


- 


[UUS-Data] 


SISE 


SISE 
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Table 6.5: Detailed Diameter ACA IVIessage Contents for Online Charging 



AVP name 


Node Type 


ECF 


Supported ACAs 


S/l/S/E 


AVPs from Diameter Base Protocol 


<Session-ID> 


SISE 


{Result Code} 


SISE 


{Origin-Host} 


SISE 


{Origin-Realm} 


SISE 


{Accounting-Record-Type} 


SISE 


{Accounting-Record-Number} 


SISE 


[Acct-Application-ID] 


- 


[Vendor-Specific-Application-ID] 


SISE 


[User-Name] 


- 


[Accounting-Sub-Session-ID] 


- 


[Accounting-RADIUS-Session-ID] 


- 


[Acct-Multi-Session-ID] 


- 


[Error-Reporting-Host] 


- 


[Acct-lnterim-lnterval] 


SIS- 


[Accounting-Realtime-Required] 


- 


[Origin-State-ID] 


SISE 


[Event-Timestamp] 


SISE 


*[Proxy-lnfo] 


- 


"[Route-Record] 


- 


AVPs from Diameter Credit Control 


[Subscription-Id] 


SISE 


[Requested-Action] 


- 


*[Requested-Service-Unit] 


- 


"[Used-Service-Unit] 


- 


[Tariff-Switch-Definition] 


SISE 


*[Service-Parameter-lnfo] 


- 


[Abnormal-Termination-Reason] 


- 


*[Accounting-Correlation-ld] 


- 


[Credit-Control-Failure-Handling] 


- 


[Direct-Debiting-Failure-Handling] 


- 


*[Granted-Service-Unit] 


SISE 


[Cost-Information) 


SISE 


[Final-Unit-lndication] 


SISE 


[Check-Balance-Result] 


SISE 


[Credit-Control-Failure-Handling] 


SISE 



AVPs Used for Offline and Online Charging 



7.1 



Diameter Base Protocol AVPs 



The use of the Attribute Value Pairs (AVPs) that are defined in the Diameter Base Protocol [3] is specified in 
subclause 5.1.3 for offline charging and in subclause 6.1.3 for online charging. The information is summarized in table 
7.1 with the base protocol AVPs listed in alphabetical order. Detailed specification of these AVPs is available in the 
base protocol specifications. 

The 3GPP IMS Charging AppUcation uses the value 10415 (3GPP) as Vendor-Id. 

Those Diameter AVPs that are used for IMS charging are marked "Yes" in table 7.1. Those Diameter AVPs that are not 
used for IMS charging are marked "No" in table 7.1. This implies that their content can (Yes) or can not (No) be used 
by the CCF or ECF for charging purposes. 
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The following symbols (adopted from [3]) are used in the tables: 

• <AVP> indicates a mandatory AVP with a fixed position in the message. 

• {AVP} indicates a mandatory AVP in the message. 

• [AVP] indicates an optional AVP in the message. 

• *AVP indicates that multiple occurrences of an AVP are possible. 

Table 7.1 : Use Of Diameter Base Protocol AVPs in IMS 



AVP name 


Mechanism 


Offline 


Online 


Type 


ACR 


ACA 


ASR 


ASA 


ACR 


ACA 


Table # 


5.4 


5.5 


5.6 


5.7 


6.2 


6.3 


[Accounting-Multi-Session-ld] 


No 


No 


- 


- 


No 


No 


[Accounting-RADIUS-Session-ld] 


No 


No 


- 


- 


No 


No 


[Accounting-Realtime-Required] 


No 


No 


- 


- 


No 


No 


{Accounting-Record-Number} 


Yes 


Yes 


- 


- 


Yes 


Yes 


{Accounting-Record-Type} 


Yes 


Yes 


- 


- 


Yes 


Yes 


[Accounting-Sub-Session-Id] 


No 


No 


- 


- 


No 


No 


[Acct-Application-ld] 


No 


No 


- 


- 


No 


No 


[Acct-lnterim-lnterval] 


Yes 


Yes 


- 


- 


Yes 


Yes 


{Auth-Application-ld} 


- 


- 


Yes 


- 


- 


- 


<Diameter-Header:271 ,REQ,PXY> 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


{Destination-Host} 


- 


- 


Yes 


Yes 


- 


- 


{Destination-Realm} 


Yes 


- 


Yes 


Yes 


Yes 


- 


[Error-IVIessage] 


- 


- 


- 


Yes 


- 


- 


[Error-Reporting-Host] 


- 


No 


- 


No 


- 


No 


[Event-Timestamp] 


Yes 


Yes 


- 


- 


Yes 


Yes 


*[Failed-AVP] 


- 


- 


- 


No 


- 


- 


*[Proxy-lnfo] 


No 


No 


No 


No 


No 


No 


{Origin-Host} 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


{Origin-Realm} 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


[Origin-State-Id] 


Yes 


Yes 


No 


No 


Yes 


Yes 


*[Redirected-Host] 


- 


- 


- 


No 


- 


- 


[Redirected-Host-Usage] 


- 


- 


- 


No 


- 


- 


[Redirected-Max-Cache-Time] 


- 


- 


- 


No 


- 


- 


{Result-Code} 


- 


Yes 


- 


Yes 


- 


Yes 


*[Route-Record] 


No 


- 


No 


- 


No 


- 


<Session-ld> 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


[User-Name] 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


[Vendor-Specific-Application-ld] 


Yes 


Yes 


- 


- 


Yes 


Yes 



NOTE: Result-Code AVP is defined in Diameter Base Protocol [3]. However new values are used in IMS 
charging applications. These additional values are defined below. 

7.1.1 Result-Code AVP 

This subclause defines new Result-Code AVP (Diameter Base Protocol [3]) values that must be supported by all 
Diameter implementations that conform to the present document. 

The Accounting-Answer message includes the Result-Code AVP, which may indicate that an error was present in the 
Accounting-Request message. A rtjtcXed Accounting-Request message should cause the user's session to be terminated. 

Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at 
the time it was received, but MAY be able to satisfy the request in the future. 



DIAMETER_END_USER_SERVICE_DENIED 



40XX 



The ECF denies the service request due to service restrictions or limitations related to the end-user, for example the 
end-user's account could not cover the requested service. 

DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 40XX 
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The credit control server determines that the service can be granted to the end user but no further credit control 
needed for the service (e.g. service is free of charge). 

Errors that fall within permanent failure category are used to inform the peer that the request failed, and should not be 
attempted again. 



DIAMETER_END_USER_NOT_FOUND 

The specified end user could not be found in the ECF. 



50XX 



7.1.2 User-Name AVP 

The User-Name AVP contains the Private User Identity [18], if available in the node. 

7.1 .3 Vendor-Specific-Application-ld AVP 



7.2 



Additional AVPs 



For the purpose of IMS charging additional AVPs are used in ACR and AC A for both online and offline charging. The 
use of these AVPs are described in subclause 5.1.3 for offline charging and in subclause 6.1.3 for online charging. The 
information is summarized in table 7.2 along with the AVP flag rules. 

Detailed descriptions of AVPs that are used specifically for IMS charging are provided in the subclauses below the 
table. However, for AVPs that are just borrowed from other applications only the reference (e.g. [13]), is provided in 
table 7.2 and the detailed description is not repeated. 

Table 7.2: Use Of Diameter Credit Control and 3GPP accounting AVPs for IMS 



AVP Name 


AVP 
Code 


Clause 
Defined 


Value Type 


AVP Flag rules 


Must 


May 


Should 
not 


Must 
not 


May 
Encr. 


AVPs from Diameter Credit Control 


[Subscription-Id] 




[13] 














[Requested-Action] 




[13] 














*[Requested-Service-Unit] 




[13] 














*[Used-Service-Unit] 




7.2.41 


Grouped 












{Unit-Type} 




7.2.38 














{Unit-Value} 




7.2.39 














{Unit-Value-After-Tariff-Switch} 




7.3.40 


Float64 












[Currency-Code] 




[13] 














[Tariff-Switch-Definition] 




7.2.34 


OctetString 












*[Service-Parameter-lnfo] 




[13] 














[Abnormal-Termination-Reason] 




[13] 














*[Accounting-Correlation-ld] 




[13] 














[Credit-Control-Failure-Handling] 




[13] 














[Direct-Debiting-Failure-Handling] 




[13] 














*[Granted-Service-Unit] 




7.2.17 


Grouped 












{Unit-Type} 




7.2.38 














{Unit-Value} 




7.2.39 














[Unit-Value-After-Tariff-Switch] 




7.3.40 


Float64 












[Currency-Code] 




[13] 














[Cost-Information] 




7.2.11 


Grouped 
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AVP Name 


AVP 
Code 


Clause 
Defined 


Value Type 


AVP Flag rules 


Must 


May 


Should 
not 


Must 
not 


May 
Encr. 


{Cost} 




[13] 














{Currency-Code} 




[13] 














[Final-Unit-lndication] 




[13] 














[Check-Balance-Result] 




[13] 














[Re-Transmission] 




[13] 














3GPP Diameter Accounting AVPs 


[Event-Type] 




7.2.14 


Grouped 












[SIP-Method] 




7.2.31 


UTF8String 












[Event] 




7.2.13 


UTF8String 












[Content-Type] 




7.2.10 


UTF8String 












[Content-Length] 




7.2.9 


UTF8String 












[Content-Disposition] 




7.2.8 


UTF8String 












[Role-of-Node] 




7.2.24 


Enumerated 












[User Session Id] 




7.2.42 


UTF8String 












[Calling-Party-Address] 




7.2.7 


UTF8String 












[Called-Party-Address] 




7.2.6 


UTF8String 












[Time-stamps] 




7.2.36 


Grouped 












[SIP-Request-Timestamp] 




7.2.32 


UTF8String 












[SIP-Response-Timestamp] 




7.2.33 


UTF8String 












[Application-server] 




7.2.3 


UTF8String 












[Application-provided-called-party- 
address] 




7.2.2 


UTF8String 












[Inter-Operator-Identifier] 




7.2.20 


Grouped 












[Originating-IOI] 




7.2.22 


UTF8String 












[Terminating-IOI] 




7.2.35 


UTF8String 












[IMS-Charging-ldentifier] 




7.2.18 


UTF8String 












*[SDP-Session-Description] 




7.2.28 


UTF8String 












*[SDP-Media-component] 




7.2.25 


Grouped 












[SDP-IVIedia-Name] 




7.2.27 


UTF8String 












*[SDP-IVIedia-Description] 




7.2.26 


UTF8String 












[GPRS-Charging-ld] 




7.2.16 


UTF8String 












[GGSN-Address] 




7.2.15 


IPAddress 












[Served-Party-IP-Address] 




7.2.29 


IPAddress 












[Authorized-QoS] 




7.2.4 


TBD 












[Server-Capabilities] 




[19] 














[Trunk-Group-Id] 




7.2.37 


Grouped 












[Incoming-Trunk-Group-Id] 




7.2.19 


UTF8String 












[Outgoing-Trunk-Group-Id] 




7.2.23 


UTF8String 












[Bearer-Service] 




7.2.5 


OctetString 












[Service- Id] 




7.2. 30 


UTF8String 












[UUS-Data] 




7.2.43 


Grouped 












[Amount-of-UUS-data] 




7.2.1 


UTF8String 












[Mime-type] 




7.2.21 


UTF8String 












[Direction] 




7.2.12 


Enumerated 













7.2.1 



Amount-of-UUS-Data AVP 



The Amount-Of-UUS-Data AVP (AVP code TBD) is of type UTFSString and holds the amount (in octets) of 
User-to-User data conveyed in the body of the SIP message with content-disposition header field equal to "render". 
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7.2.2 Application-Provided-Called-Party-Address AVP 

The Application-Provided-Called-Party-Address AVP (AVP code TBD) is of type UTFSString and holds the called 
party number (SIP URL, E.164), if it is determined by an application server. 

7.2.3 Application-Server AVP 

The Application-Server AVP (AVP code TBD) is of type UTFSString and holds the SIP URL(s) of the AS(s) addressed 
during the session. 

7.2.4 Autinorised-QoS AVP 

The Authorised-QoS AVP (AVP code TBD) is of type (TBD) and holds the Authorised QoS as defined in TS 23.207 [7] 
/ TS 29.207 [8] and applied via the Go interface. 

7.2.5 Bearer-Service AVP 

The Bearer-Service AVP (AVP code TBD) is of type OctetString and holds the used bearer service for the PSTN leg. 

7.2.6 Called-Party-Address AVP 

The Called-Party-Address AVP (AVP code TBD) is of type UTFSString and holds the address (Public User ID: SIP 
URL, E.164, etc.) of the party to whom a session is established. 

7.2.7 Calling-Party-Address AVP 

The Calling-Party-Address AVP (AVP code TBD) is of type UTFSString and holds the address (Public User ID: SIP 
URL, E.164, etc.) of the party initiating a session. 



7.2.8 Content-Disposition AVP 



The Content-Disposition AVP (AVP code TBD) is of type UTFSString and indicates how the message body or a 
message body part is to be interpreted (e.g. session, render), as described in [17]. 



7.2.9 Content-Length AVP 

The Content-Length AVP (AVP code TBD) is of type UTFSString and holds the size of the of the message-body, as 
described in [17]. 

7.2.10 Content-Type AVP 

The Content-Type AVP (AVP code TBD) is of type UTFSString and holds the media type (e.g. application/sdp, 
text/html) of the message-body, as described in [17]. 

7.2.1 1 Cost-Information AVP 

The Cost-Information AVP (AVP Code TBD) is of type Grouped and is used to return the cost information of a service 
in the Accounting- Answer command. The included Cost AVP contains the cost of the service event and the 
Currency-Code specifies in which currency the cost was given. 

When the Requested-Action AVP with value PRICE_ENQUIRY is included in the Accounting-Request command the 
Cost-Information AVP sent in the succeeding Accounting-Answer command contains the cost estimation of the 
requested service, without any reservation being made. 

The Cost-Information AVP included in th& Accounting- Answer command with the Accounting-Record-Type set to 
INTERIM_RECORD contains the accumulated cost for the session without taking any credit- reservation into account. 
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The Cost-Information AVP included in the Accounting- Answer command with the Accounting-Record-Type set to 
EVENT_RECORD or STOP_RECORD contains the total cost for the requested service. It has the following ABNF 
grammar. 

When the Requested- Action AVP is set to RESERVE_UNITS in the Accounting-Request (ACR) and the Unit-Type in 
the Requested-Service-Unit AVP is set to SERVICE_CREDIT_MONEY, the Cost-Information AVP sent in the 
succeeding Accounting Answer (ACA) contains the requested cost information. 

It has the following ABNF grammar: 

<Cost-Information>; ;=<AVP Header: TBD> 

{ Cost } 

{ Currency-Code } 

7.2.12 Direction AVP 

The Direction AVP (AVP code TBD) is of type Enumerated and indicates whether the UUS data travels in up-link or 
down-link direction. The following values are defined: 

UPLINK 

DOWNLINK 1 

7.2.13 Event AVP 

The Event AVP (AVP code TBD) is of type UTFSString and holds the content of the "Event" header used in 
SUBSCRIBE and NOTIFY messages. 



7.2.14 Event-Type AVP 



Reflects the type of chargeable telecommunication service/event for which the accounting-request message is 
generated, such as: "session", "register", "subscribe". 

The IMS-Event-Type AVP (AVP code TBD) is of type Grouped and contains information about the type of chargeable 
telecommunication service/event for which the accounting-request message is generated. 

It has the following ABNF grammar: 

<IMS-Event-Type>::=<AVP Header: TBD > 

[ SIP-Method] 

[ Event ] 

[ Content-Type ] 

[ Content-Length ] 

[ Content-Disposition ] 

7.2.15 GGSN-Address AVP 

The GGSN-Address AVP (AVP code TBD) is of type IP Address and holds the IP-address of the GGSN that generated 
the GPRS Charging ID, as described in [2]. 



7.2.1 6 GPRS-Cinarging-ID AVP 



The GPRS-Charging-ID AVP (AVP code TBD) is of type UTFSString and holds a sequence number generated by the 
GGSN at PDP context activation, as described in [2]. 
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7.2.1 7 Granted-Service-Unit AVP 

If the ACA containing the Granted-Service-Unit AVP contains a Tariff-Switch-Definition AVP, the Unit-Value -After- 
Tariff-Switch AVP may be included. In this case the Unit-Value AVP contains the granted units before the tariff switch 
time and the Unit-Value-After-Tariff-Switch AVP gives the units granted after the tariff switch. 

If the ACA containing the Granted-Service-Unit AVP contains a Tariff-Switch-Definition AVP but no Unit-Value- 
After-Tariff-Switch AVP is included, the granted Unit-Value is used before and after the tariff switch. 

An ACA containing a Granted-Service-Unit AVP with Unit-Value-After-Tariff-Switch AVP MUST contain a Tariff- 
Switch-Definition AVP. If the Tariff-Switch-Definition AVP is missing, the Unit-Value-After-Tariff-Switch AVP is 
ignored and it is proceeded as without a tariff change. 

It has the following ABNF grammar: 

<Granted-Service-Unit>::=< AVP Header: TBD > 

{ Unit-Type } 

{ Unit- Value } 

[ Unit- Value- After-Tariff Switch ] 

[ Currency-Code ] 

7.2.18 IMS-Charging-ldentifier (ICID) AVP 

The IMS-Charging-Identifier AVP (AVP code TBD) is of type UTFSString and holds the IMS Charging Identifier 
(ICID) as generated by a IMS node for a SIP session and described in subclause 5.2.4.10. 

7.2.19 Incoming-Trunk-Group-ID AVP 

The Incoming-Trunk-Group-ID AVP (AVP code TBD) is of type UTFSString and identifies the incoming PSTN leg. 

7.2.20 Inter-Operator-Identifier (101) AVP 

The Inter-Operator-Identifier AVP (AVP code TBD) is of type Grouped and holds the identification of the network 
neighbours (originating and terminating) as exchanged via SIP signalling and described in [15]. 

It has the following ABNF grammar: 

<Inter-Operator-Identifier>::=< AVP Header: TBD > 

[ Originating-IOI ] 

[ Terminating-IOI ] 

7.2.21 Mime-Type AVP 

The Mime-Type AVP (AVP code TBD) is of type UTFSString and holds the Mime type of the User-To-User data. 

7.2.22 Originating-IOI AVP 

The Originating-IOI AVP (AVP code TBD) is of type UTFSString (alphanumeric string) and holds the Inter Operator 
Identifier for the originating network as generated by the S-CSCF in the home network of the originating end user [15]. 

7.2.23 Outgoing-Trunk-Group-ID AVP 

The Outgoing-Trunk-Group-ID AVP (AVP code TBD) is of type UTFSString and identifies the outgoing PSTN leg. 
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7.2.24 Role-of-Node AVP 

The Role-Of-Node AVP (AVP code TBD) is of type Enumerated and specifies the role of the CSCF, as relevant for the 
chargeable telecommunication service/event. 

The identifier can be one of the following: 

ORIGINATING_ROLE 

The CSCF is applying a originating role, serving the calling subscriber. 

TERMINATING_ROLE 1 

The CSCF is applying a terminating role, serving the called subscriber. 

7.2.25 SDP-Media-Component AVP 

The SDP- Media-Component AVP (AVP code TBD) is of type Grouped and contains information about media used for 
a IMS session. 

It has the following ABNF grammar; 

<SDP-Media-Component>::=<AVP Header: TBD > 

[ SDP-Media-Name ] 

*[ SDP-Media-Description ] 

[ GPRS-Charging-Id ] 

7.2.26 SDP-Media-Description AVP 

The SDP-Media-Description AVP (AVP code TBD) is of type UTFSString and holds the content of an "attribute-hne" 
(i=, c=, b=, k=, a=) related to a media component, as described in [17]. The attributes are specifying the media 
described in the SDP-Media-Name AVP. 

7.2.27 SDP-Media-Name AVP 

The SDP-Media-Name AVP (AVP code TBD) is of type UTFSString and holds the content of a "m=" line in the SDP 
data. 



7.2.28 SDP-Session-Description AVP 

The SDP-Media-Description AVP (AVP code TBD) is of type UTFSString and holds the content of an "attribute-hne" 
(i=, c=, b=, k=, a=) related to a media component, as described in [17]. 

7.2.29 Served-Party-IP-Address AVP 

The Served-Party-IP-Address AVP (AVP code TBD) is of type IP Address and holds the IP address of either the calling 
or called party, depending on whether the proxy is in touch with the calling or the called party. 

7.2.30 Service-ID AVP 

The Service-ID AVP (AVP code TBD) is of type UTFSString and identifies the service the MRFC is hosting. For 
conferences the conference ID is used as the value of this parameter. 

7.2.31 SIP-Method AVP 

The SIP-Method AVP (AVP code TBD) is of type UTFSString and holds the name of the SIP Method (INVITE, 
UPDATE etc.) causing an accounting request to be sent to the CCF. 
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7.2.32 SIP-Request-Timestamp AVP 

The SIP-Request-Timestamp AVP (AVP code TBD) is of type UTFSString and holds the time in UTC format of the 
initial SIP request (e.g. Invite). 

7.2.33 SIP-Response-TimestampAVP 

The SIP-Response-Timestamp AVP (AVP code TBD) is of type UTFSString and holds the time in UTC format of the 
response to the initial SIP request (e.g. 200 OK). 

7.3.34 Tariff-Switch-Definition AVP 

The Tarijf-Switch-Definition AVP (AVP Code TBD) is of type OctetString and contains the tariff switch timer. 

This AVP can be included in the Accounting Answer which is sent as a result of the previous Accounting Request with 
Requested-Action AVP set to RESERVE_UNITS. The tariff switch timer is evaluated relative to the timestamp of the 
preceding Accounting Request command. When the tariff switch timer expires, the AS/MRFC uses the 
Unit-Value-After-Tariff-Switch, if provided in the ACA, as granted units. 

If a tariff switch has occurred, the Tariff-Switch-Definition AVP should be included in the next ACR together with the 
units used before the tariff switch (Unit-Value AVP) and the units used after the tariff switch 

(Unit-Value-After-Tariff-Switch AVP). 

7.2.35 Terminating-IOI AVP 

The Terminating-IOI AVP (AVP code TBD) is of type UTFSString (alphanumeric string) and holds the Inter Operator 
Identifier for the originating network as generated by the S-CSCF in the home network of the terminating end user [15]. 

7.2.36 Time-Stamps AVP 

The Time-Stamp AVP (AVP code TBD) is of type Grouped and holds the time of the initial SIP request and the time of 
the response to the initial SIP Request. 

It has the following ABNF grammar: 

<Time-Stamps>::=< AVP Header: TBD > 

[SIP-Request-Timestamp] 

[SIP-Response-Timestamp] 

7.2.37 Trunk-Group-ID AVP 

The Trunk-Group-ID AVP (AVP code TBD) is of type Grouped and identifies the incoming and outgoing PSTN legs. 
It has the following ABNF grammar: 

<Trunk-Group-ID>::=<AVP Header: TBD> 

[ Incoming-Trunk-Group-ID ] 

[ Outgoing-Trunk-Group-ID ] 
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7.2.38 Unit-Type AVP 

The Unit-Type AVP is of type Enumerated (AVP Code TBD) and contains the type of the unit. The unit type can be one 
of the following: 

SERVICE_CREDIT_TIME 

The unit is of type "time" and is given in seconds. 

SERVICE_CREDIT_VOLUME 1 

The unit is of type "volume" and is given in kB. 

SERVICE_CREDIT_EVENT 2 

The unit is of type "event" and is given as a number of events. 

SERVICE_CREDIT_MONEY 3 

The unit is of type "money" and is given as a monetary value, whose currency SHOULD be specified by the 
Currency-Code AVP. 

SERVICE_CREDIT_SERVICE 4 

The unit of type "service" and is given as a selected service. 

7.2.39 Unit-Value AVP 

The Unit-Value AVP is of type Float64 (AVP Code TBD) and contains the granted or used Unit- Value. The value can 
be time in seconds, volume in kB, number of events or monetary amount depending on the given Unit-Type. 

If the Unit-Type AVP is set to "time" in \ht Accounting-Answer cov[ma.nd, the Unit Value AVP specifies the granted 
time in seconds (measured from the moment when the services becomes active or from the previous Answer command) 
until a new Accounting-Request MUST be sent. 

If the Unit Type AVP is set to "time" in ihs Accounting-Request command, the Unit-Value AVP specifies the used time 
since previous report or time requested by the service element (e.g. AS/MRFC). 

If the Unit-Type AVP is set to "volume" in the Accounting- Answer command, the Unit-Value AVP specifies the granted 
volume in kB (measured from the moment when the services becomes active or from the previous Answer command) 
until a new Accounting-Request MUST be sent. If the Unit-type AVP is set to "volume" in the Accounting-Request 
command, the Unit-Value AVP specifies the used volume since previous report or volume requested by service element 
(e.g. AS/MRFC). 

If the Unit-Type AVP is set to "event" in \he. Accounting-Answer covarasxid, the Unit-Value AVP specifies the granted 
number of events (measured from the moment when the service becomes active or from the previous Answer 
command) until a new Accounting-Request MUST be sent. If the Unit-type AVP is set to "event" in the Accounting- 
Request command, the Unit-Value AVP specifies the used number of events since previous report or number of events 
requested by the service element (e.g. AS/MRFC). 

If the Unit-Type AVP is set to "money" in \hc Accounting-Answer covava^inA, the Unit-Value AVP specifies the granted 
monetary amount, which the end user can use until a new Accounting-Request MUST be sent. If the Unit-Type AVP is 
set to "money" in the Accounting-Request command, the Unit-Value AVP specifies the used monetary amount since 
previous report or the monetary amount requested by the service element (e.g. AS/MRFC). 

If the Accounting- Answer command contains a Tariff-Switch-Definition AVP and a Unit-Value-After-Tariff-Switch 
AVP, the Unit-Value AVP in the Accounting-Answer contains the amount of units granted before the tariff change. In 
this case, the following holds: 



• 



If the Unit-Type AVP is set to "time" in the Accounting-Answer command, the Unit Value AVP specifies the 
granted time before the tariff switch in seconds (measured from the moment when the services becomes active or 
from the previous Answer command) until the tariff switch occurs or a new Accounting-Request MUST be sent. 
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• If the Unit-Type AVP is set to "volume" in the Accounting-Answer command, the Unit-Value AVP specifies the 
granted volume before the tariff switch in kB (measured from the moment when the services becomes active or 
from the previous Answer command) until the tariff switch occurs or a new Accounting-Request MUST be sent. 

• If the Unit-Type AVP is set to "event" in the Accounting- Answer command, the Unit-Value AVP specifies the 
granted number of events before the tariff switch (measured from the moment when the service becomes active 
or from the previous Answer command) until the tariff switch occurs or a new Accounting-Request MUST be 
sent. 

• If the Unit-Type AVP is set to "money" in the Accounting- Answer command, the Unit-Value AVP specifies the 
granted monetary amount before the tariff switch, which the end user can use until the tariff switch occurs or a 
new Accounting-Request MUST be sent. 

If the Accounting- Answer command contains a Tariff-Switch-Definition AVP but no Unit-Value-After-Tariff-Switch 
AVP, the Unit-Value AVP in the Accounting- Answer contains the total amount of units granted irrespective of the tariff 
change. 

If the Accounting-Answer command contains a Tariff-Switch-Definition AVP and a tariff switch occurred, the next 
Accounting-Request contains the Unit-Value AVP and the Unit-Value-After-Tariff-Switch AVP. The Unit-Value AVP 
contains the service units used before the tariff switch. 

7.3.40 Unit-Value-After-Tariff-Switch AVP 

The Unit-Value-After-Tariff-Switch AVP is of type Float64 (AVP Code TBD) and contains the granted or used 

Unit- Value after a tariff switch. The value can be time in seconds, volume in kB, number of events or monetary amount 

depending on the given Unit-Type. 

The Unit-Value-After-Tariff-Switch AVP can only occur in combination with a Tariff-Switch-Definition AVP. 

If the Unit-Type AVP is set to "time" in the Accounting-Answer command, the Unit-Value-After-Tariff-Switch AVP 
specifies the granted time in seconds (measured from the moment when the tariff change occurs) until a new 
Accounting-Request MUST be sent. 

If the Unit Type AVP is set to "time" in the Accounting-Request command, the Unit-Value-After-Tariff-Switch AVP 
specifies the used time after tariff switch. 

If the Unit-Type AVP is set to "volume" in the Accounting- Answer command, the Unit-Value-After-Tariff-Switch AVP 
specifies the granted volume in kB (measured from the moment when the tariff change occurs) until a new 
Accounting-Request MUST be sent. If the Unit-type AVP is set to "volume" in the Accounting-Request command, the 
Unit-Value-After-Tariff-Switch AVP specifies the used volume after tariff switch. 

If the Unit-Type AVP is set to "event" in the Accounting-Answer command, the Unit-Value-After-Tariff-Switch AVP 
specifies the granted number of events (measured from the moment when the tariff change occurs) until a new 
Accounting-Request MUST be sent. If the Unit-type AVP is set to "event" in the Accounting-Request command, the 
Unit-Value-After-Tariff-Switch AVP specifies the used number of events after tariff switch. 

If the Unit-Type AVP is set to "money" in the Accounting-Answer command, the Unit-Value-After-Tariff-Switch AVP 
specifies the granted monetary amount, which the end user can use (measured from the moment when the tariff change 
occurs) until a new Accounting-Request MUST be sent. If the Unit-Type AVP is set to "money" in the 
Accounting-Request command, the Unit-Value-After-Tariff-Switch AVP specifies the used monetary amount after tariff 
switch. 

7.2.41 Used-Service-Unit AVP 

The Used-Service-Unit AVP is of type Grouped AVP (AVP Code TBD) and contains the amount of used units since the 
previous Accounting-Answer command. The included Unit-Type AVP defines the type of the unit and the Unit-Value 
AVP contains the used amount. If the unit type is "money", a Currency-Code AVP SHOULD be included. 

If the previous AC A contained a Tariff-Switch-Definition AVP, the Unit-Value-After-Tariff-Switch AVP must be 
included in the Used-Service-Unit AVP in the ACR, if the tariff switch was encountered. In this case the Unit-Value 
AVP contains the units used before the tariff switch and the Unit-Value-After-Tariff-Switch AVP gives the units used 
after the tariff switch. 
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It has the following ABNF grammar: 

<Used-Service-Unit>::=< AVP Header: TBD > 
{ Unit-Type } 
{ Unit- Value } 

{ Unit-Value-After-Tariff-Switch } 
[ Currency-Code ] 

7.2.42 User-Session-ID AVP 

The User-Session-Id AVP (AVP code TBD) is of type UTFSString and holds the session identifier. For a SIP session 
the Session-ID contains the SIP Call ID, as defined in [16]. 

7.2.43 UUS-Data AVP 

The UUS-Data AVP (AVP Code TBD) is of type Grouped AVP and holds information about the sent User-To-User 
data. 

It has the following ABNF grammar: 

<Used-Service-Unit>::=< AVP Header: TBD > 

[Amount-of-UUS-Data] 

[Mime-Type] 

[Direction] 
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